NASA/CR-20 14-2 1 8244 



Formal Methods Case Studies for DO-333 


Darren Cofer and Steven P. Miller 
Rockwell Collins, Inc., Cedar Rapids, Iowa 


April 2014 


NASA STI Program ... in Profile 


Since its founding, NASA has been dedicated to the 
advancement of aeronautics and space science. The 
NASA scientific and technical information (STI) 
program plays a key part in helping NASA maintain 
this important role. 

The NASA STI program operates under the 
auspices of the Agency Chief Information Officer. 

It collects, organizes, provides for archiving, and 
disseminates NASA’s STI. The NASA STI 
program provides access to the NASA Aeronautics 
and Space Database and its public interface, the 
NASA Technical Report Server, thus providing one 
of the largest collections of aeronautical and space 
science STI in the world. Results are published in 
both non-NASA channels and by NASA in the 
NASA STI Report Series, which includes the 
following report types: 

• TECHNICAL PUBLICATION. Reports of 
completed research or a major significant phase 
of research that present the results of NASA 
Programs and include extensive data or 
theoretical analysis. Includes compilations of 
significant scientific and technical data and 
information deemed to be of continuing 
reference value. NASA counterpart of peer- 
reviewed formal professional papers, but 
having less stringent limitations on manuscript 
length and extent of graphic presentations. 

• TECHNICAL MEMORANDUM. Scientific 
and technical findings that are preliminary or of 
specialized interest, e.g., quick release reports, 
working papers, and bibliographies that contain 
minimal annotation. Does not contain extensive 
analysis. 

• CONTRACTOR REPORT. Scientific and 
technical findings by NASA-sponsored 
contractors and grantees. 


• CONFERENCE PUBLICATION. 

Collected papers from scientific and 
technical conferences, symposia, seminars, 
or other meetings sponsored or co- 
sponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 
technical, or historical information from 
NASA programs, projects, and missions, 
often concerned with subjects having 
substantial public interest. 

• TECHNICAL TRANSLATION. 
English-language translations of foreign 
scientific and technical material pertinent to 
NASA’s mission. 

Specialized services also include organizing 
and publishing research results, distributing 
specialized research announcements and feeds, 
providing information desk and personal search 
support, and enabling data exchange services. 

For more information about the NASA STI 
program, see the following: 

• Access the NASA STI program home page 
at http://www.sti.nasa.sov 

• E-mail your question to help@sti.nasa.gov 

• Fax your question to the NASA STI 
Information Desk at 443-757-5803 

• Phone the NASA STI Information Desk at 
443-757-5802 

• Write to: 

STI Information Desk 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 


NASA/CR-20 14-2 1 8244 



Formal Methods Case Studies for DO-333 


Darren Cofer and Steven P. Miller 
Rockwell Collins, Inc., Cedar Rapids, Iowa 


National Aeronautics and 
Space Administration 

Langley Research Center Prepared for Langley Research Center 

Hampton, Virginia 23681-2199 under Contract NNL06AA04B 


April 2014 


The use of trademarks or names of manufacturers in this report is for accurate reporting and does not constitute an 
official endorsement, either expressed or implied, of such products or manufacturers by the National Aeronautics 
and Space Administration. 


Available from: 

NASA Center for AeroSpace Information 
7115 Standard Drive 
Hanover, MD 21076-1320 
443-757-5802 





Table of Contents 


Acknowledgements 11 

Abstract 12 

1 Introduction 13 

2 Example: Dual-Channel Flight Guidance System 17 

3 Case Study: Theorem Proving 21 

3 . 1 Overview of FGS System 21 

3.2 Software Verification Plan 23 

3.2.1 Formal Specification and Verification Tools 23 

3.2.2 Fife Cycle Data Items 23 

3.2.3 Objectives to Be Satisfied 24 

3.2.4 Tool Qualification Issues 28 

3.3 The Synchronous Pilot Flying Example 31 

3.3.1 High-Fevel Requirements for the Synchronous Bus 31 

3.3.2 Fow-Fevel Requirements for the Synchronous Bus 35 

3.3.3 High-level Requirements for the Synchronous FGS Side 37 

3.3.4 Fow-level Requirements for the Synchronous FGS Side 41 

3.3.5 PVS Specification of the Synchronous Pilot Flying System 45 

3.3.6 Formal Verification of the Synchronous Pilot Flying Example 48 

3.4 The Asynchronous Pilot Flying Example 58 

3.4.1 Specification of the Asynchronous Bus Messages 59 

3.4.2 High-Fevel Requirements for the Asynchronous Bus 59 

3.4.3 Fow-Fevel Requirements for the Asynchronous Bus 60 

3.4.4 High-Fevel Requirements for the Asynchronous FGS Side 62 


1 



3.4.5 Low-Level Requirements for the Asynchronous FGS Side 67 

3.4.6 PVS Specification of the Asynchronous Pilot Flying Example 70 

3.4.7 Formal Verification of the Asynchronous Pilot Flying Example 73 

3.5 The Synchronous Pilot Flying Example in HOL 84 

3.5.1 Specification in HOL4 using a Next-State Approach 84 

3.5.2 Formal Verification of the Next-State Approach in HOL4 87 

3.5.3 Specification in HOL4 using a Streams Approach 90 

3.5.4 Formal Verification of the Streams Approach in HOL4 93 

4 Case Study: Model Checking 95 

4. 1 Mode Logic Overview 95 

4.2 Software Verification Plan 98 

4.2. 1 Formal Specification and Verification Tools 98 

4.2.2 Life Cycle Data Items 99 

4.2.3 Objectives to Be Satisfied 99 

4.2.4 Tool Qualification Issues 103 

4.3 Specification of the Mode Logic 104 

4.3.1 Flight Modes 106 

4.3.2 Event Processing 132 

4.4 Formal Verification of the Mode Logic 136 

4.4. 1 Heuristics for Writing Formal Properties 136 

4.4.2 Verification of the Mode Logic Using the Kind Model Checker 138 

4.4.3 Verification of the Mode Logic Using MATLAB Design Verifier 153 

5 Case Study: Abstract Interpretation 158 

5.1 Overview of the Heading Control Model 158 


2 



5.1.1 Heading Control Model and Code 158 

5.1.2 Properties to Be Checked 161 

5.2 Software Verification Plan 162 

5.2.1 Life Cycle Data Items 164 

5.2.2 Objectives to Be Satisfied 164 

5.2.3 Tool Qualification Issues 167 

5.3 Analysis of the Heading Control Law Source Code with Astree 167 

5.4 Analysis of the Heading Control Law Source Code with Polyspace 169 

6 Conclusion 172 

7 References 173 

Appendix A Acronyms 175 

Appendix B Mode Logic Properties 177 

Appendix C Mode Logic Error Log 198 


3 



Figures 


Figure 1 - Relationship of Elements of the Dual-channel FGS Example 14 

Figure 2 - Relationship of Case Studies to DO-178C Objectives 15 

Figure 3 - Overview of the Flight Guidance System 17 

Figure 4 - Flight Control Panel 18 

Figure 5 - Primary Flight Display 19 

Figure 6 - FGS System Function 21 

Figure 7 - Synchronous Pilot Flying System 31 

Figure 8 - High-Level Requirements for the Synchronous Bus 32 

Figure 9 - Low-Level Requirements for the Synchronous Bus 35 

Figure 10 - Theory Interpretation for Synchronous Bus 36 

Figure 1 1 - TCCs Generated from Theory Interpretation for the Synchronous Bus 37 

Figure 12 - Synchronous Pilot Flying Side Logic 38 

Figure 13 - High-Level Requirements for the Synchronous Side (Part 1) 39 

Figure 14 - High-Level Requirements for the Synchronous Side (Part 2) 40 

Figure 15 - Low-Level Requirements for the Synchronous Side (Part 1) 42 

Figure 16 - Low-Level Requirements for the Synchronous Side (Part 2) 43 

Figure 17 - Theory Interpretation for the Synchronous Side 44 

Figure 18 - PVS Specification of the Synchronous Pilot Flying System (Part 1) 45 

Figure 19 - PVS Specification of the Synchronous Pilot Flying System (Part 2) 46 

Figure 20 - Incorrect Statement of Synchronous Requirement R1 in PVS 48 

Figure 21 - Synchronous Pilot Flying System Requirements (Part 1) 49 

Figure 22 - Correct Statement of Requirement R1 in PVS 50 

Figure 23 - PVS Proof of Synchronous Reachable States Valid Theorem 5 1 

Figure 24 - Inductive Sequent for Reachable States 51 

Figure 25 - Synchronous Pilot Flying System Requirements (Part 2) 52 

Figure 26 - PVS Proof of Requirement R1 for Synchronous Pilot Flying System 53 

Figure 27 - PVS Specification of the Pilot Flying System Requirements (Part 3) 54 

Figure 28 - PVS Proof of Requirement R3a/b for Synchronous Pilot Flying System 55 

Figure 29 - Pilot Flying System Requirements 2 56 

Figure 30 - PVS Proof of Switching Transient 57 


4 



Figure 3 1 - Asynchronous Pilot Flying System 58 

Figure 32 - PVS Specification of a Bus Message 59 

Figure 33 - High-Level Requirements for the Asynchronous Bus 60 

Figure 34 - Low-Level Requirements for the Asynchronous Bus 61 

Figure 35 - Theory Interpretation for Asynchronous Bus 62 

Figure 36 - Asynchronous Pilot Flying Side Logic 63 

Figure 37 - High-Level Requirements for the Asynchronous Side (Part 1) 64 

Figure 38 - High-Level Requirements for the Asynchronous Side (Part 2) 65 

Figure 39 - High-Level Requirements for the Asynchronous Side (Part 3) 66 

Figure 40 - High-Level Requirements for the Asynchronous Side (Part 4) 67 

Figure 41 - Low-Level Requirements for the Asynchronous Side (Part 1) 68 

Figure 42 - Low-Level Requirements for the Asynchronous Side (Part 2) 69 

Figure 43 - Theory Interpretation for the Asynchronous Side 70 

Figure 44 - PVS Specification of the Asynchronous Pilot Flying Example - Part 1 71 

Figure 45 - PVS Specification of the Asynchronous Pilot Flying Example - Part 2 72 

Figure 46 - Asynchronous Pilot Flying System Requirements (Part 1) 74 

Figure 47 - Asynchronous Pilot Flying System Requirements (Part 2) 75 

Figure 48 - Asynchronous Pilot Flying System Requirements (Part 3) 76 

Figure 49 - Lemmas Added to Side HLR to Support Theorem Proving 78 

Figure 50 - Grind-use-grind PVS Proof Strategy 79 

Figure 51 - PVS Proof of Asynchronous Reachable States Valid Theorem 79 

Figure 52 - Asynchronous Pilot Flying System Requirements (Part 4) 80 

Figure 53 - Incorrect Statement of Asynchronous Requirement R3 80 

Figure 54 - Asynchronous Pilot Flying System Requirements (Part 5) 81 

Figure 55 - Incorrect Statement of Asynchronous Requirement R5 82 

Figure 56 - Asynchronous Pilot Flying System Requirements (Part 6) 83 

Figure 57 - Rise and Data Type Definitions 85 

Figure 58 - Initial State Definitions 86 

Figure 59 - Next State Definitions 87 

Figure 60 - Valid State Definition 88 

Figure 61 - Custom Simplification Set sys_ss 89 


5 



Figure 62 - H0L4 Proof that all Reachable States are Valid 89 

Figure 63 - HOL4 Proof that All Valid States Satisfy R1 90 

Figure 64 - HOL4 Proof that All Valid States Satisfy R1 90 

Figure 65 - Bus Specification with Streams Approach 90 

Figure 66 - Two-Delay Bus Specification with Streams Approach 91 

Figure 67 - ‘Rise’ Definition with Streams Approach 91 

Figure 68 - Alternate ‘Rise’ Definition with Streams Approach 91 

Figure 69 - System Specification with Streams Approach 92 

Figure 70 - Side Specification with Streams Approach 92 

Figure 71 - Final Bus Specification for Streams Approach 93 

Figure 72 - Statement of R4 Property 93 

Figure 73 - Statement of R1 Property 93 

Figure 74 - Proof of R4 Property for Streams Approach 94 

Figure 75 - Proof of R1 Property for Streams Approach 94 

Figure 76 - A Non- Arming Mode 96 

Figure 77 - An Arming Mode 96 

Figure 78 - A Capture/Track Mode 97 

Figure 79 - Mode Logic Top Level 105 

Figure 80 - Flight Modes Subsystem 106 

Figure 81 - FD Mode Logic 107 

Figure 82 - ANNUNCIATIONS Mode Logic 109 

Figure 83 - LATERAL Modes 110 

Figure 84 - Heading Select (HDG) Mode 1 12 

Figure 85 - Lateral Navigation (NAV) Mode 113 

Figure 86 - Lateral Approach (LAPPR) Mode 115 

Figure 87 - Lateral Go Around (LGA) Mode 117 

Figure 88 - Roll Hold (ROLL) 118 

Figure 89 - VERTICAL Modes 120 

Figure 90 - Vertical Speed (VS) Mode 121 

Figure 91 - Flight Level Change (FLC) Mode 123 

Figure 92 - Altitude Hold (ALT) Mode 125 


6 



Figure 93 - Altitude Select (ALTSEL) Mode 126 

Figure 94 - Vertical Approach (VAPPR) Mode 128 

Figure 95 - Vertical Go Around (VGA) Mode 130 

Figure 96 - Pitch Hold (PITCH) Mode 132 

Figure 97 - Event Processing 133 

Figure 98 - Seen Logic 134 

Figure 99 - At Least One Lateral Mode Active (Lustre) 138 

Figure 100 - Weaker Version of at Least One Lateral Mode Active (Lustre) 139 

Figure 101 - At Most One Lateral Mode Active (Lustre) 140 

Figure 102 - VAPPR Active Only If LAPPR Active (Lustre) 141 

Figure 103 - LGA Active If and Only If VGA Active (Lustre) 141 

Figure 104 - Overspeed Implies FLC, ALT, ALTSEL, or PITCH Active (Lustre) 142 

Figure 105 - Overspeed and PITCH Transitory (Lustre) 142 

Figure 106 - HDG Switch Pressed Selects HDG (Lustre) 143 

Figure 107 - Definition of RISING (Lustre) 143 

Figure 108 - HDG Switch Pressed Selects HDG Using Internal Variables (Lustre) 144 

Figure 109 - No Higher Event Than HDG Switch Pressed (Lustre) 145 

Figure 1 10 - Functional Requirements for Clearing HDG Mode (Lustre) 145 

Figure 1 1 1 - Initial Functional Requirements for Activating NAV Mode (Lustre) 146 

Figure 1 12 - Correct Functional Requirements for Activating NAV Mode (Lustre) 146 

Figure 1 13 - VGA Clear Error 147 

Ligure 114 -Counterexample for Clearing VGA Error 148 

Figure 1 15 - Counterexample for FLC Select Error 150 

Figure 1 16 - ALTSEL Select Error (Lustre) 151 

Figure 1 17 - Counterexample for ALTSEL Select Error 152 

Figure 1 18 - At Least One Lateral Mode Active (Design Verifier) 153 

Figure 1 19 - NAV Active When Capture Cond Met (Design Verifier) 154 

Figure 120 - At Least One Vertical Mode Active (Design Verifier) 154 

Figure 121 - Properties Subsystem (Design Verifier) 155 

Figure 122 - Top-Most Model (Design Verifier) 157 

Figure 123 - Heading Control Law Model 159 


7 



Figure 124 - Fragment of Autogenerated C Code for Heading Control Model 160 

Figure 125 - Astree Analysis Results 168 

Figure 126 - Astree Directives to Define Partitions 169 

Figure 127 - Anti-Windup Logic 170 


8 



Tables 


Table 1 - Summary of Objectives Satisfied by Theorem Proving 25 

Table 2 - Summary of Objectives Satisfied by Model Checking 101 

Table 3 - Turn FD On 107 

Table 4 - Lateral Mode Manually Selected 108 

Table 5 - Vertical Mode Manually Selected 108 

Table 6 - Turn FD Off 108 

Table 7 - Turn Annunciations On 109 

Table 8 - Turn Annunciations Off 109 

Table 9 - New Lateral Mode Activated Ill 

Table 10-HDG Select 112 

Table 11 -HDG Clear 113 

Table 12 - HDG Will Be Activated 1 13 

Table 13-NAV Select 114 

Table 14 - NAV Capture 114 

Table 15 -NAV Clear 114 

Table 16 - NAV Will Be Activated 115 

Table 17 - LAPPR Select 115 

Table 18 - LAPPR Capture 116 

Table 19 - LAPPR Clear 116 

Table 20 - LAPPR Will Be Activated 1 16 

Table 21 - LGA Select 117 

Table 22 -LGA Clear 118 

Table 23 - LGA Will Be Activated 118 

Table 24 - Lateral Mode Active 119 

Table 25 - New Vertical Mode Activated 121 

Table 26 - VS Select 122 

Table 27 - VS Clear 122 

Table 28 - VS Will Be Activated 122 

Table 29 - FLC Select 123 

Table 30 - FLC Clear 124 


9 



Table 3 1 - FLC Will Be Activated 124 

Table 32 -ALT Select 125 

Table 33 -ALT Clear 126 

Table 34 - ALT Will Be Activated 126 

Table 35 - ALTSEL Select 127 

Table 36 - ALTSEL Capture 127 

Table 37 - ALTSEL Track 127 

Table 38 - ALTSEL Clear 128 

Table 39 - ALTSEL Will Be Activated 128 

Table 40 - VAPPR Select 129 

Table 41 - VAPPR Capture 129 

Table 42 - VAPPR Clear 129 

Table 43 - VAPPR Will Be Activated 130 

Table 44 -VGA Select 131 

Table 45- VGA Clear 131 

Table 46 - LGA Will Be Activated 131 

Table 47 - Vertical Mode Active 132 

Table 48 - FLC Select Error 149 

Table 49 - Summary of Objectives Satisfied by Abstract Interpretation 165 

Table 50 - Initial Polyspace Analysis Results 169 

Table 51 - Unproven Runtime Checks 171 

Table 52 - Coding Rules Analysis 171 


10 



Acknowledgements 

Several individuals contributed to the case studies described in this report. Darren Cofer of 
Rockwell Collins provided general oversight and developed the sections on meeting DO-333 
objectives and tool qualification. Steven P. Miller and Jennifer Davis of Rockwell Collins 
developed the Pilot Flying theorem proving case study based on PVS with assistance from 
Konrad Slind, also of Rockwell Collins. Jennifer Davis and Konrad Slind provided the HOL4 
version of the Pilot Flying case study. Cesar Munoz of the NASA Langley Research Center 
provided valuable input regarding tool qualification and soundness for the PVS theorem prover. 
Sam Owre of SRI International and Mike Whalen of the University of Minnesota provided 
assistance on the use of PVS. 

Steven P. Miller developed the Mode Logic model checking case study based on MATLAB 
Simulink/Stateflow® and the Kind and MATLAB Design Verifier™ model checkers with 
assistance from Andrew Gacek and Daren Cofer of Rockwell Collins. Cesare Tinelli of the 
University of Iowa provided valuable input regarding tool qualification and soundness for the 
Kind model checker. 

Michael Dierkes of Rockwell Collins France developed the Heading Control abstract 
interpretation case study based on Astree. Sidhartha Battacharyya of Rockwell Collins developed 
the Polyspace® version of the same case study. Gary Balas of the University of Minnesota 
provided the Heading Control flight control law. 


11 



Abstract 


RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A provides guidance for 
software developers wishing to use formal methods in the certification of airborne systems and 
air traffic management systems. The supplement identifies the modifications and additions to 
DO-178C and DO-278 A objectives, activities, and software life cycle data that should be 
addressed when formal methods are used as part of the software development process. This 
report presents three case studies describing the use of different classes of formal methods to 
satisfy certification objectives for a common avionics example - a dual-channel Flight Guidance 
System. The three case studies illustrate the use of theorem proving, model checking, and 
abstract interpretation. The material presented is not intended to represent a complete 
certification effort. Rather, the purpose is to illustrate how formal methods can be used in a 
realistic avionics software development project, with a focus on the evidence produced that could 
be used to satisfy the verification objectives found in Section 6 of DO-178C. 
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1 Introduction 


RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A [35] provides guidance 
for software developers wishing to use formal methods in the certification of airborne systems 
and air traffic management systems. The supplement identifies the modifications and additions 
to DO-178C [33] objectives, activities, and software life cycle data that should be addressed 
when formal methods are used as part of the software development process. This includes 
artifacts that would be expressed using some formal notation and the verification evidence that 
could be derived from them. 

This report presents three case studies describing the use of different classes of fonnal methods 
to satisfy DO-178C certification objectives. The material presented is not intended to represent a 
complete certification effort. Rather, the purpose is to illustrate how formal methods can be used 
in a realistic avionics software development project, with a focus on the evidence produced that 
could be used to satisfy the verification objectives found in Section 6 of DO-178C. 

The case studies examine different aspects of a common avionics example - a dual-channel 
Flight Guidance System (FGS) shown in Figure 1. While not intended as a complete example, it 
is representative of the issues encountered in actual avionics development projects and includes 
design artifacts specified using PVS, MATLAB Simulink/Stateflow®, and C source code. These 
files are available for download and use without restriction from the same site where this report 
is posted. A description of this example is provided in Section 2. 

The three case studies illustrate the use of theorem proving, model checking, and abstract 
interpretation. Each of these techniques has strengths and weaknesses, and each could be applied 
to different life cycle data items and different objectives than those described here. The purpose 
here is to illustrate a reasonable application of each of these techniques for satisfying 
certification objectives. 

DO-333 provides general guidance that is applicable to the overall verification process when 
formal methods are used. This includes requirements for the use of formal notations with 
unambiguous, mathematically defined syntax and semantics, soundness of the formal analysis 
methods used, and justification of all assumptions used in each fonnal analysis. Specific 
guidance is provided to describe how formal methods can be applied within each of the 
verification activities and objectives defined in DO-178C. This is illustrated in Figure 2 for 
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Level A software, the highest criticality level defined in DO-178C. These include compliance 
with requirements, accuracy and consistency of requirements, compatibility with the target 
computer, verifiability of requirements, conformance to standards, traceability between life cycle 
data items, and algorithmic correctness. Some of the objectives do not need to be satisfied for 
the less critical Level C or Level D software. 
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Figure 1 - Relationship of Elements of the Dual-channel FGS Example 
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As shown in Figure 2, theorem proving was applied to the verification of the High-Level 
Requirements, model-checking was applied to verification of the Low-Level Requirements and 
Software Architecture, and abstract interpretation was applied to verification of the Source Code. 
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Diagram adapted from DO-333 Formal Methods 
Supplement to DO-178C and DO-278A 


Development Activity 
Review/Analysis Activity 

► Test Activity 

Note: Requirements include Derived Requirements 


Figure 2 - Relationship of Case Studies to DO-178C Objectives 

Theorem proving was applied to the verification of the High-Level Requirements for the 
synchronization of the two channels of the FGS, focusing on the objectives of DO-333 Table 
FM.A-3. Theorem proving is generally considered the most powerful and versatile class of 
formal methods, but it is also the least automated, and usually requires the significant expertise 
and user training. This case study is described in Section 3. 
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Model checking was applied to the verification of the Low-Level Requirements for the mode 
logic of a single FGS channel, focusing on the objectives of DO-333 Table FM.A-4. Current 
model checking tools are very powerful and provide much more automation than theorem 
provers. In general, less user expertise is required, but the user must be able to specify 
requirements to be analyzed in a formal language. These tools are relatively mature and (in our 
opinion) the benefits of using fonnal methods are greatest at this level. This case study is 
described in Section 4. 

Abstract interpretation was applied to the Source Code implementing one of the control laws of 
the FGS, focusing on the objectives of DO-333 Table FM.A-5. Abstract interpretation is the 
most automated of the three techniques, at least as used in currently available commercial tools, 
and typically require the least expertise from users. Part of this is due to the use of abstract 
interpretation to check non-functional requirements, eliminating the need to formally specify 
requirements. We should note, however, that more powerful versions of abstract interpretation 
tools exist which require much more expertise to specify and check user-defined abstract 
domains. This case study is described in Section 5. 

Each case study includes: 

• A general description of the portion of the example system to be verified 

• A description of the verification approach used, including the life cycle data items 
produced and the tools used, roughly corresponding to some of the information that 
should be included in a Software Verification Plan 

• The objectives to be satisfied and the evidence produced 

• Tool qualification issues relevant for the formal methods tools used 

• A detailed description of the verification effort that was performed 

As a result of the tools and objectives we have chosen for these case studies, there are some parts 
of DO-333 that are not covered. In particular, we do not address the verification of Executable 
Object Code (Table FM.A-6 objectives), nor do we address the replacement of coverage testing 
by fonnal analysis (Table FM.A-7 objectives). 
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2 Example: Dual-Channel Flight Guidance System 

We will illustrate the use of formal methods to satisfy DO-178C objectives with three case 
studies built around a common avionics example, a dual-channel Flight Guidance System (FGS). 
In this chapter, we provide a high level description of the FGS and how it interacts with the other 
avionics systems and with the flight crew. 

An FGS is a component of the overall Flight Control System (FCS). It compares the measured 
state of an aircraft (position, speed, and attitude) to the desired state and generates pitch and roll 
guidance commands to minimize the difference between the measured and desired state. An 
overview of an FCS that emphasizes the role of the FGS is shown in Figure 3. 



Figure 3 - Overview of the Flight Guidance System 

As shown in Figure 3 the FGS subsystem accepts input about the aircraft's state from the 
Attitude Heading Reference System (AHRS), the Air Data System (ADS), the Flight 
Management System (FMS), and the Navigation Radios. Using this information, it computes 
pitch and roll guidance commands that are provided to the autopilot (AP). When engaged, the 
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AP translates these commands into movement of the aircraft's control surfaces necessary to 
achieve the commanded changes about the lateral and vertical axes. 


The flight crew interacts with the FGS primarily through the Flight Control Panel (FCP), shown 
in Figure 4. The FCP includes switches for turning the Flight Director (FD) on and off, switches 
for selecting the different flight modes such as vertical speed (VS), lateral navigation (NAV), 
heading select (HDG), altitude hold (ALT), and approach (APPR), the Vertical Speed/Pitch 
Wheel, and the AP disconnect bar. The FCP also supplies feedback to the crew, indicating 
selected modes by lighting lamps on either side of a selected mode's button. 
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Figure 4 - Flight Control Panel 

A few key controls, such as the Go Around button, the AP Disengage switch, and the SYNC 
switch are provided on the control yokes and throttles and routed through the FCP to the FGS. 
Navigation sources are selected through the Display Control Panel (DCP), with the selected 
navigation source routed through the PFD to the FGS. 

As shown in Figure 3, the FGS has two physical sides, or channels, one on the left side and one 
on the right side of the aircraft. These provide redundant implementations that communicate with 
each other over a cross-channel bus. Each channel of the FGS can be further broken down into 
the mode logic and the flight control laws. The flight control laws accept information about the 
aircraft's current and desired state and compute the pitch and roll guidance commands. A flight 
control law is active if its guidance commands are being used to control the aircraft or to provide 
visual cues to the flight crew. A flight control law that is operational but that is not yet active is 
anned. The mode logic detennines which lateral and vertical modes of operation are active (e.g. 
controlling the aircraft or providing visual guidance cues to the flight crew) and armed (e.g. 
operational but not yet active) at any given time. These in turn determine which flight control 
laws are active and armed. These are annunciated, or displayed, on the Primary Flight Displays 
(PFD) along with a graphical depiction of the flight guidance commands generated by the FGS. 
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A simplified image of a Primary Flight Display (PFD) is shown in Figure 5. The PFDs display 
essential infonnation about the aircraft, such as airspeed, vertical speed, attitude, the horizon, and 
heading. The active lateral and vertical modes are displayed (annunciated) at the top of the 
display. The annunciations in Figure 5 indicate that the current active lateral mode is Roll Hold 
(ROLL), the active vertical mode is Pitch Hold (PITCH), and that the Altitude Select (ALTSEL) 
mode is armed. 


Lateral Mode 
Annunciations 

AP Engagement 
Indicator 



Figure 5 - Primary Flight Display 

The large sphere in the center of the PFD is the attitude indicator. The horizontal line across its 
middle is the artificial horizon. The current pitch and roll of the aircraft is indicated by a white 
wedge representing the aircraft in the middle of the attitude indicator. Figure 5 depicts an 
aircraft in level flight with zero degrees of roll and zero degrees of pitch. 

The graphical presentation of the pitch and roll guidance commands on the PFD are referred to 
as the Flight Director (FD) 1 . The pitch and roll guidance commands are shown as a grey wedge 
in the sky/ground bah. When the AP is not engaged, these are interpreted as guidance to the 
pilot. When the AP is engaged, these indicate the direction the aircraft is being steered by the 


The term Flight Director is also commonly used to refer to the logic that computes the pitch and roll guidance 
commands. 
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AP. Engagement of the AP is indicated by the letters AP displayed directly under the mode 
annunciations. Figure 5 depicts an aircraft in which the AP is engaged and the FD is 
commanding the pilot to pitch up 7.5 degrees. 

In most flight modes, the FGS operates in dependent mode where only one FGS channel is active 
and provides guidance to the FD and the AP. The other side serves as a hot spare and sets its 
modes to match those of the active side. This is indicated by the Pilot Flying indicator displayed 
directly below the mode annunciations which points to the pilot flying (active) side. In some of 
the more critical modes such as Approach, Takeoff, and Go Around, the FGS operates in 
independent mode where both channels are active and independently computing guidance 
commands that must agree for the AP to be engaged. 
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3 Case Study: Theorem Proving 

This section illustrates the use of theorem proving to verify important system properties of the 
dual-channel FGS. We demonstrate the use of two different interactive theorem proving tools: 
PVS and HOL4. The majority of the case study is carried out using PVS, and then repeated (on 
a part of the example) using HOL4 to illustrate the differences in the approaches. 

The rest of this section is organized as follows. Section 3.1 provides an overview of the FGS 
system and the functionality that we will be verifying in this case study. Section 3.2 describes 
the software verification plan, identifying the life-cycle data items to be produced, the DO-178C 
objectives to be satisfied, and tool qualification issues. Section 3.3 describes the synchronous 
example, including how the components are specified in PVS, how the entire system is 
composed from the components, and how the system requirements are verified. Section 3.4 
extends the synchronous example to the asynchronous case by introducing independent clocks 
for each component and repeats the verification. Finally, Section 3.5 presents an alternative 
specification and verification of the synchronous example using HOL4. 

3.1 Overview of FGS System 

The overall FGS system has two physical sides, or channels, one on the left side and one on the 
right side of the aircraft. These provide redundant implementations that communicate with each 
other over a cross-channel bus as shown in Figure 6. 



Figure 6 - FGS System Function 

Most of the time, the FGS operates in dependent mode where only one FGS channel is active and 
provides guidance to the FD and the AP. In this mode, the flight crew can choose whether the 
left or the right FGS is the active or pilot flying side by pressing the Transfer Switch located 
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above the FCP. The other side serves as a hot spare and sets its modes to agree with those of the 
active side. In some of the more critical modes such as Approach, Takeoff, and Go Around, the 
FGS operates in independent mode where both channels are active and independently compute 
guidance commands that must agree for the AP to be engaged, regardless of which side is the 
current pilot flying side. 

In this example, there are five system level requirements related to the synchronization of the 
pilot flying side. Stated informally, these are: 

R1 . At least one side shall be the pilot flying side. 

R2. At most one side shall be the pilot flying side. 

R3. Pressing the Transfer Switch shall always change the pilot flying side. 

R4. The system shall start with the Primary Side as the pilot flying side. 

R5. The system shall not change the pilot flying side unless the Transfer Switch is pressed. 
Note that these requirements are system-level requirements that encompass the two sides of the 
FGS and the cross-channel bus between them. 

The overview of Figure 6 provides no indication whether the two FGS execute synchronously or 
asynchronously. In some designs, such as in a Time-Triggered Architecture (TTA), all 

components are driven off of a single master clock and execute synchronously. In other 

architectures, such as Avionics Full-Duplex Switched Ethernet (AFDX), each component is 
driven by its own local clock and the components execute asynchronously relative to each other. 

In this case study we first develop a synchronous design in which all components are driven from 
single master clock. We develop a set of high-level requirements for each FGS side and the 
cross-channel bus that are completely free of design detail. Using theorem proving, we show that 
these high-level requirements are consistent (i.e. do not contradict each other) by proving that 
there is at least one concrete implementation that satisfies the high-level component 
requirements. We then show that the system architecture and the high-level requirements of the 
components comply with the system requirements by proving that the system requirements are 
satisfied by the synchronous design instantiated with any components that satisfy the high-level 
component requirements. We then extend this example to the more complex asynchronous case 
by introducing independent clocks for each component. 
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3.2 Software Verification Plan 

In this case study, we will use theorem proving to verify the outputs of the software requirements 
process (DO-178C Section 5.1) focusing on the objectives of Table A-3 in DO-178C and Table 
FM.A-3 in DO-333. The purpose of these verification activities is to detect any errors that may 
have been introduced during the software requirements process. Specifically, this case study will 
verify the high-level software requirements for the synchronization of the pilot flying side of the 
FGS and show that the system architecture, the high-level software requirements, and the high- 
level hardware requirements comply with the system requirements. 

3.2.1 Formal Specification and Verification Tools 

The PVS formal specification language will be used to specify the system architecture, system 
requirements, high-level software and hardware requirements of the system components, and 
candidate low-level software and hardware requirements of the system components. Verification 
of all fonnal properties will be perfonned using the PVS theorem proving system. 

3.2.2 Life Cycle Data Items 

Life cycle data items are provided for both the synchronous and asynchronous examples using 
the PVS formal specification language. To facilitate comparison of the two examples, the same 
names are used for comparable data items in each example. 

System Architecture The system architecture is captured in the PVS theory Pilot Flying System. 
This theory describes how the system components interact in the overall system. 

System Requirements The system requirements are stated formally as theorems in the PVS 
theory Pilot _Flying _Sy stem Requirements. Machine checked proofs are developed in 
PVS to prove that these requirements are satisfied by the system architecture and the 
high-level requirements for the system components. 

High-Level Software Requirements The high-level software requirements are specified for each 
FGS side in the Side HLR theory. This theory uses axioms and uninterpreted types, 
constants, and functions to eliminate design detail from the requirements. The axioms are 
proven consistent by demonstrating that at least one concrete implementation exists that 
satisfies the axioms. 
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Low-Level Software Requirements Candidate low-level requirements are specified for an FGS 
side in the Side LLR theory. This theory uses interpreted types, constants, and functions 
to define a specification that is consistent-by-construction. The Side lnterpretation 
theory is used to prove that the low-level requirements comply with (i.e. implement) the 
high-level requirements, proving that the high-level requirements are consistent. 

High-Level Hardware Requirements The high-level hardware requirements are specified for the 
cross-channel bus in the Bus HLR theory. This theory uses axioms and uninterpreted 
types, constants, and functions to eliminate all design detail from the requirements. The 
axioms are proven consistent by demonstrating that at least one concrete implementation 
exists that satisfies the axioms. 

Low-Level Hardware Requirements Candidate low-level requirements are specified for the cross- 
channel bus in the Bus LLR theory. This theory uses interpreted types, constants, and 
functions to define a specification that is consistent-by-construction. The 
Bus -Interpretation theory is used to prove that the low-level requirements comply with 
(i.e. implement) the high-level requirements, proving that the high-level requirements are 
consistent. 

The low-level requirements for each FGS side and the cross-channel bus exist primarily to prove 
that the high-level requirements are consistent. While they could be used as the actual low-level 
requirements for a development, a more likely scenario is that more detailed low-level 
requirements would be developed and proven to comply with (i.e. implement) the high-level 
requirements. So long as the more detailed requirements maintain the same interface and are 
proven to satisfy the high-level requirements, they can be substituted for the low-level 
requirements without invalidating the verification of the system requirements. 

3.2.3 Objectives to Be Satisfied 

The DO-178C and DO-333 objectives to be satisfied through theorem proving are summarized in 
Table 1. Columns A through D in the table indicate for each DO-178C software level whether 
that objective must be satisfied, and if the objective has been fully or partially satisfied in the 
case study using fonnal methods. A more detailed discussion of how each objective is satisfied 
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is provided in this section. The discussion here is focused on the PVS version of the 
specification. 


Table 1 - Summary of Objectives Satisfied by Theorem Proving 


Objective 

Description 

A 

B 

C 

D 

Notes 

A-3.1 

High-level requirements 
comply with system 
requirements. 

■ 

■ 

■ 

■ 

Established by proof the system requirements are 
implemented by the high-level requirements and the 
system architecture. 

A-3.2 

High-level requirements are 
accurate and consistent. 

■ 

■ 

■ 

■ 

Accuracy is established by formalization of the high- 
level requirements. Consistency is established by 
proving the absence of logical conflicts. 

A-3.3 

High-level requirements are 
compatible with target 
computer. 





Not addressed 

A-3.4 

High-level requirements are 
verifiable. 

■ 

■ 


_ 

Established by formalizing the requirements and 
completion of the proof. 

A-3.5 

High-level requirements 
conform to standards. 

□ 

□ 

□ 


Partially established by specifying the high-level 
requirements as formal properties. 

A-3.6 

High-level requirements are 
traceable to system 
requirements. 

■ 

■ 


■ 

Established by verification of the system requirements, 
and by demonstrating the necessity of each high-level 
requirement for satisfying some system requirement. 

A-3.7 

Algorithms are accurate. 

■ 

■ 



Correctness of the pilot flying selection logic is 
established by proof. 

FM.A-3.8 

Formal analysis cases and 
procedures are correct. 

■ 

■ 


L 

Established by review. 

FM.A-3.9 

Formal analysis results are 
correct and discrepancies 
explained. 

■ 

■ 


L 

Established by review. 

FM.A-3.10 

Requirements formalization 
is correct. 

■ 

■ 


□ 

Established by review. 

FM.A-3.1 1 

Formal method is correctly 
defined, justified, and 
appropriate. 

■ 

■ 


■ 

Established by review. 


■ Full credit claimed □ Partial credit claimed Satisfaction of objective Is at applicant’s discretion 


Objective A-3.1 - High-level requirements comply with system requirements. This objective is 
demonstrated by proving with the PVS theorem prover that the system level requirements 
specified as theorems in theory Pilot_Flying_System_Requirements are implemented by the 
system architecture defined in theory Pilot _Flying_Sy stem, the high-level software requirements 
specified as axioms in theory SideHLR and the high-level hardware requirements specified as 
axioms in theory Bus HLR. 

Objective A-3.2 High-level requirements are accurate and consistent. Accuracy is demonstrated by 
formalizing the high-level software requirements as axioms in the PVS theory Side HLR. 
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Consistency is demonstrated by proving that the concrete implementation defined in SideLLR 
implements the axioms of SideHLR. This is done by mapping in theory Side interpretation 
each uninterpreted type, constant, and function in Side HLR to its interpreted counterpart in 
Side LLR and proving that the axioms of Side HLR are implemented by Side LLR. 

Objective A-3.4 High-level requirements are verifiable. This objective is demonstrated by 
formalizing the high-level software requirements as axioms in the PVS theory Side HLR and 
proving that axioms are satisfied by the concrete implementation defined in Side LLR. 

Objective A-3.5 High-level requirements conform to standards. This objective is partially 
demonstrated by formalizing the high-level software requirements as axioms in the PVS theory 
Side HLR, establishing that the requirements conform to the PVS specification language. 
Additional standards, such as naming standards or the presence of comments providing rationale 
for the requirement, are verified by review. 

Objective A-3.6 High-level requirements are traceable to system requirements. This objective is 
demonstrated by the proof that the high-level requirements comply with the system requirements 
(objective A-3.1) and by commenting out the high-level requirements one at a time and showing 
that the proof of the system requirements fail without each high-level requirement. 

Objective A-3.7 Algorithms are accurate. This objective is demonstrated by proving that the 
system-level requirements specified in theory Pilot _Flying_Sy stem Requirements are 
implemented by the system architecture specified in the theory Pilot _Flying_System when 
instantiated with the high-level requirements specified in theory Side HLR and Bus HLR. 

Objective FM.A-3.8 Formal analysis cases and procedures are correct. This objective is met 
through review to ensure that the analyses and procedures satisfy the objectives A-3.1 through 
A-3.7 for which credit is claimed. The soundness of the proofs is ensured by the PVS verification 
system once the consistency of all axioms is verified and all types are shown to be non-empty. 
The remaining reviews consist of validating any assumptions. This includes: 

• Confirming that the resolution of cyclic dependencies in the theory Pilot _Flying_System 
is correct and can be implemented. 

• Confirming that the addition of asynchronous clocks conservatively models the behavior 
of the asynchronous system. 
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• Confirming that assumption that the Transfer Switch is observed by both sides in the 
same step is acceptable. 

Objective FM.A-3.9 Formal analysis results are correct and discrepancies explained. This objective 
is met through review to ensure that all theorems or lemmas are proven. The PVS verification 
system will identify any proofs that cannot be completed or that depend on a proof that cannot be 
completed. Many of the properties had to be revised before they could be proved. Typically, 
these were due to omissions in the original requirements or oversights introduced by the 
informality of textual requirements. For example, the requirement R2 “At most one side shall be 
the pilot flying side” had to be changed to “At most one side shall be the pilot flying side except 
while the system is switching sides. ” Each such discrepancy was explained and fed back into the 
safety assessment process for review. 

Objective FM.A-3.10 Requirements formalization is correct. This objective is met through review to 
ensure that the fonnal statement of a requirement is a conservative representation of the informal 
requirement. 

Objective FM.A-3.11 Formal method is correctly defined, justified, and appropriate. This objective 
is met through a review to ensure: 

a. All notations used for fonnal analysis are verified to have precise, unambiguous, 
mathematically defined syntax and semantics. Only the PVS language was used which 
provides a fonnal syntax and semantics. 

b. The soundness of each formal analysis method is normally demonstrated by citing 
research papers that discuss the soundness of the method(s) implemented in a given tool. 
In the case of PVS, it may be necessary to restrict the use of certain proof strategies for 
which evidence of soundness is not available. At a minimum, it must be shown that all 
axioms are consistent and all types are non-empty. Soundness of both PVS and HOL4 is 
discussed further in the next section in the context of tool qualification. 

c. Assumptions related to each fonnal analysis are described and justified. The one 
assumption described above that both sides observe the Transfer Switch in the same step 
is shown to be acceptable since only the pilot not flying side listens for the Transfer 
Switch. Since this example contains only Boolean and enumerated types and no other 


27 



relationships are assumed about its inputs, no assumptions related to the formal analysis 
(e.g., approximating floating-point numbers as reals) were necessary. 

3.2.4 Tool Qualification Issues 

Tool qualification is the process necessary to obtain certification credit for the use of a software 
tool within the context of a specific airborne system. It is likely that any formal methods tool 
used for verification as described in DO-333 will require qualification. 

According to DO-178C, qualification of a tool is needed when: 

1. DO-178C processes are eliminated, reduced, or automated through the use of the tool, 
and 

2. The output of the tool is used without being verified. 

The purpose of qualification is to ensure that the tool provides confidence at least equivalent to 
that of the process which is eliminated, reduced, or automated. 

DO-178C specifies that tool qualification should be performed in accordance with DO-330, 
Software Tool Qualification Considerations [34]. DO-330 specifies five different Tool 
Qualification Levels (TQLs) that define what activities must be perfonned to qualify a particular 
software tool. DO-178C, in turn defines three criteria to determine to determine which TQL 
should apply to a particular tool in a given context. 

Criteria 1 : A tool whose output is part of the airborne software and thus could insert an error. 

Criteria 2: A tool that automates verification processes and thus could fail to detect an error, and 
whose output is used to justify the elimination or reduction of either verification processes other 
than those automated by the tool, or development processes that could have an impact on the 
airborne software. 

Criteria 3: A tool that, within the scope of its intended use, could fail to detect an error (in other 
words, a tool that automates verification processes). 

Once the criteria are applied, DO-178C provides a table in section 12.2.2 to map software level 
and qualification criteria to the required TQL. For the certification objectives and tool use that 
we are considering in this case study, Criteria 3 applies. This means that for all airborne 
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software levels the theorem provers would need to be qualified to TQL-5 (if their results are not 
independently checked). 

Depending on the tool, qualification of a theorem prover may be a difficult task. Even at the 
lowest qualification level (TQL-5) there are a number of development artifacts that must be 
produced as part of the qualification process. The largest part of the effort is focused on defining 
operational requirements for the tool (what the tool claims to do - the processes eliminated, 
reduced, or automated), and then developing a comprehensive test suite to show that those 
requirements are satisfied over an appropriate range of tool inputs. 

An alternative approach is to avoid the need to qualify the theorem prover itself by providing an 
independent check of the proof it produces. This may be more or less feasible depending on the 
nature of the proof artifacts generated by a particular theorem prover. 

The PVS proof engine is built from a small set of primitive inference steps. Most of the inference 
steps are small, but a few involve deep combinations of decision procedures and rewriting. 
Larger proof strategies can be defined using the primitive ones. Several external proof tools for 
Binary Decision Diagram (BDD)-based simplification and model checking, monadic second- 
order reasoning, nonlinear arithmetic, and predicate abstraction have been added to PVS. 

PVS is based on a classical strongly-typed higher-order logic and the theorem prover itself is a 
based on a sequent calculus for this logic. Standard references for the PVS language are [29], 
[30], [31] and [32], However, not all aspects of the language are described. Lor example, the 
formal semantics of recursive functions and their termination is not described. This would likely 
present some challenges to qualification and the requirement to demonstrate soundness of the 
analysis method. 

Unlike Isabelle/HOL or Coq, PVS does not normally emit a proof that could be checked by a 
separate (qualified) proof checking tool, though this option is available. We have expanded one 
of our proofs down to the primitive proof rules to demonstrate that this is feasible. Depending 
upon the nature of the proof rules used, this expansion could in principle be independently 
checked by a separate tool. However, we are not aware of this having been done in practice and 
development of an appropriate independent checker for PVS is still a research topic. 
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Extant implementations of HOL follow the so-called “LCF approach” to designing theorem 
provers. This methodology implements the logic by a small trusted kernel, which encapsulates 
just the primitive inference rules, axioms, and definition mechanisms of the logic. The logic 
kernel is an abstract data type, having the property that the only way a theorem can be obtained 
is ultimately by making primitive inference steps, which are very close in granularity to those in 
the mathematical definition of the logic. For example, the introduction and elimination rules for 
the logical connectives constitute the bulk of the implementation of the HOF4 kernel, and these 
are very simple to implement. In contrast, basic inference steps in systems like PVS tend to be 
much larger, amounting to invocation of complex combinations of simplifiers and powerful 
decision procedures. 

As a consequence, it is straightforward to instrument HOF kernels so that they produce fonnal 
proofs. This has been done in a variety of research projects [28], [15]. Programs that check the 
correctness of such proofs are small and relatively easy to verify. 

Another approach to theorem prover correctness is to verily the kernel once and for all. This has 
been done for the implementations of the primitive inferences of HOF Fight, with respect to an 
abstract, set-theoretic specification of the logic. 

A more extensive overview of the issues for PVS and HOF4, as well as other popular theorem 
proving environments, can be found in the summary document for the “Trusted Extensions of 
Interactive Theorem Provers” workshop [36]. 
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3.3 The Synchronous Pilot Flying Example 

The synchronous Pilot Flying example consists of four main components, the Left_Side FGS, the 
Right Side FGS, an LR Bus and an RL Bus connecting the two sides as shown in Figure 7. 


Left_Pilot_Flying_Side 



Right_Pilot_Flying_Side 


Figure 7 - Synchronous Pilot Flying System 

All four components are assumed to be driven by the same master clock and to execute 
synchronously. Each FGS produces a Pilot _Flying_Side Boolean output indicating if it believes 
itself to be the current pilot flying side. The two buses pass the value produced by one side to the 
other side, introducing a one-step delay in the process. Each FGS accepts as inputs a Boolean 
value representing the current value of the Transfer _Switch 2 and the Pilot _Flying_Side value 
passed across the bus from the other side. Each FGS also accepts a single Boolean constant 
indicating if it is the Primary _Side that is to be the initial pilot flying side. The constant for the 
Lefi Side is set to true to make it the initial pilot flying side while the input to the Right _Side is 
set to false. The intermediate connections Cl, C2, C3, and C4 are also labeled on the diagram to 
facilitate discussion of the formal specification and the proofs. 

3.3.1 High-Level Requirements for the Synchronous Bus 

Each bus in the synchronous Pilot Flying example transfers its input to its output with a one-step 
delay. The PVS theory specifying this behavior is shown in Figure 8. 


2 . . 

“ Note that there is an implied assumption in this model that the Transfer Switch arrives at both sides on the same 
step. The subsequent discussion shows that this assumption can be safely made since only the pilot not flying side 
listens for the Transfer Switch and no more than one side is ever the pilot not flying side. 
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Bus_HLR[ Init: bool]: THEORY 
BEGIN 

% 

% State defined as an uninterpreted, non-empty type 

% 

State: TYPE+ 

Initial_State : State 

% 

% Next state defined as an uninterpreted function 

% 

next_state: [State, bool -> State] 

% 

% Output of the bus 

% 

output: [State -> bool] 

% 

% High level requirements 

% 

HLR1 : AXIOM 

output ( Initial_State ) = Init 
HLR2 : AXIOM 

forall (s: State, i: bool) : 

output ( next_state ( s , i)) = i 


END Bus HLR 


Figure 8 - High-Level Requirements for the Synchronous Bus 

Since the bus introduces a one-step delay in conveying its inputs to its outputs, the initial output 
value of the bus must be specified. This is done by parameterizing the theory with the Init 
Boolean value. To be able to compose all the components of the Pilot Flying System in a 
consistent fashion, we adopt the convention of defining a State type for each component 
representing its internal state. Since we want the high-level requirements to be as free of design 
decisions as possible, we define the type State for the synchronous bus to be an uninterpreted 
type that provides no information about how the state is implemented. Since an empty type can 
lead to an unsound proof system, we do specify that the type must have at least one value by 
defining it to PVS as a TYPE+. We also define an uninterpreted constant Initial State to be an 
element of this type. As its name implies, Initial State will represent the initial state of the bus at 
start-up. 
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While the type of the internal state of a component can be defined in PVS, PVS does not provide 
a mechanism for persisting state as might be done in an object-oriented system. Instead, the 
current state is passed in as an argument of each function that manipulates it. We adopt the 
convention of defining for each component a next_state function that compute the component’s 
next state from its current state and its inputs and an output function that returns the outputs of 
the component from its current state. For the synchronous bus, the next_state function takes a 
state s of the bus and a Boolean input, and returns the next internal state of the bus. The output 
function takes a state s and returns a Boolean value. 

The high-level requirements for the synchronous bus are specified as two PVS axioms. The first 
requirement, HLR1, simply states that the output of the Initial State is the Boolean value Init 
specified as the theory parameter. The second requirement, HLR2, states that the output of the 
next _st ate of any state 5 and any input i is i. 

These axioms were defined through use of a well-known heuristic for writing axiomatic, or 
declarative, specifications. We first identify all constructors that generate new values of the type 
State and all extractors that extract values from elements of the type State. For the synchronous 
bus, the constructors are Initial_State and next _st ate and the only extractor is output. We then 
write one or more axioms that describe the result of applying each extractor to each constructor. 
For the synchronous bus, this results in the two axioms shown in Figure 8. 

Writing requirements as axioms allows us to specify the required behavior of a component 
without committing to a specific design or implementation. Note that these axioms only specify 
the functionality of a component. In particular, we have not stated whether they are system, 
software, or hardware requirements. They could be viewed as the high-level functional system 
requirements for the bus. If the bus is to be implemented primarily in software, they could also 
be used as the high-level functional software requirements. If the bus is to be implemented 
primarily in hardware, they could be used as the high-level functional hardware requirements. 
Such axiomatic or declarative specifications are fonnal versions of the informal “shall” 
statements typically written in requirements documents. In fact, they share two common 
concerns with such requirements, completeness and consistency. 

Completeness refers to whether the axioms (requirements) fully specify what needs to be built. 
We address this issue in two ways. First, we used the heuristic described earlier to define the 


33 



effect of each extractor on each constructor, giving us a systematic way of developing the 
axioms. More importantly, we prove in Section 3.3.6 that the requirements for the overall Pilot 
Flying system will be satisfied using any bus that satisfies these axioms, showing that the axioms 
are sufficiently complete to ensure the required system behavior. 

Consistency refers to whether the axioms contradict each other. In an informal development 
process, inconsistent requirements are typically discovered during development when it becomes 
apparent that the specified system cannot be built. In the same way, inconsistent axioms cannot 
be implemented. Even worse, inconsistent axioms introduce unsoundness into a proof system 
allowing false theorems to be proven. For this reason, whenever axioms are used in a 
specification, it is important to prove that they are consistent. The standard way of doing this is 
to demonstrate that an implementation exists that satisfies all the axioms. In the next section, we 
define a set of low-level requirements for the bus that are consistent by construction and prove 
that the implementation satisfies the high-level axioms. 
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3.3.2 Low-Level Requirements for the Synchronous Bus 

A PVS theory for an implementation of the synchronous bus is shown in Figure 9. 

Bus_LLR [ Init : bool ] : THEORY 
BEGIN 

% 

% Define the bus state and initial state 

% 

State: TYPE = bool 

Initial_State : State = Init 

% 

% Next state function 

% 

next_state ( s : State, i: bool): State = i 

% 

% Output of the bus 

% 

output(s: State): bool = s 

END Bus LLR 


Figure 9 - Low-Level Requirements for the Synchronous Bus 

As with the high-level requirements, the theory is parameterized with the initial output value of 
the bus. We also introduce a type State and a constant Initial State of that type. However, this 
time we give each of these a concrete interpretation. We define the State of the bus to be of type 
Boolean and we assign the theory parameter Init to be the value of Initial State. We also provide 
a concrete interpretation for each function. We define the next_state function to return the value 
of its input i and we define the output of the bus to be its current state s. 

Note that this specification does not include any axioms. It is constructed using only the base 
types of PVS and functions. The PVS type system will ensure that such a constructive 
specification is consistent by generating type-correctness conditions (TCCs) that must be proven 
using the PVS theorem prover. 

This specification is notable in that is actually shorter than the high-level bus requirements. 
However, it is also more concrete in that it makes the design decision to represent the state of the 
channel as a single Boolean variable. We could have also chosen to implement the bus using an 
integer rather than a Boolean or using a queue of size one providing the constructor and extractor 
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functions were defined appropriately. So long as an implementation provides the same types, 
constants, and functions and satisfies the two axioms of the high-level requirements of Figure 8, 
it would be an acceptable implementation of the synchronous bus. 

To prove that the low-level bus requirements of Figure 9 implement, or comply with, the high- 
level bus requirements of Figure 8, we use the theory interpretation capability of PVS. This is 
shown in Figure 10. The Bus -Interpretation theory first imports the BusLLR theory using the 
same Boolean theory parameter, Init. It then imports the BusHLR theory, but provides an 
interpretation for each uninterpreted type, constant, and function based on the Bus LLR 
specification. For example, it defines the State type of the Bus HLR theory to be the State type 
of the Bus LLR theory. In fact, it defines each uninterpreted type, constant and function in 
Bus HLR to be the corresponding type, constant, or function in Bus LLR. When this theory is 
typechecked using PVS, it generates the two TCCs shown in Figure 11. 


Bus_Interpretation [ Init : bool] : THEORY 
BEGIN 

% 

% Import low-level requirements (LLR) for a bus 

% 

IMPORTING Bus_LLR [ Init ] 

% 

% Import high-level (HLR) requirements for a bus and 
% define the LLR as an interpretation of the HLR 

% 

IMPORTING Bus_HLR[ Init] {{ 

State := Bus_LLR . State , 

Initial_State := Bus_LLR . Initial_State , 

next_state := Bus_LLR . next_state , 

output := Bus_LLR . output 

}} 

END Bus_Interpretation 


Figure 10 - Theory Interpretation for Synchronous Bus 

A careful examination of these TCCs reveals that they are the axioms of the Bus HLR theory 
instantiated with the types, constants, and functions defined in the Bus LLR theory. These TCCs 
can easily be proved using the typecheck-prove (M-x tcp) command of PVS, proving that the 
Bus LLR theory implements the axioms of the Bus HLR theory. 
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% 

Mapped- 

axiom TCC generated (at line 

14, column 

12) 

for 


% Bus 

_HLR[ Init] 





% 

{{ State := Bus LLR. State, 





% 

Initial State := Bus LLR. 

Initial State, 



% 

next state := Bus LLR. next state. 




% 

output := Bus LLR. output 

}} 




% proved - complete 




IMP_Bus_HLR_HLRl_TCCl : OBLIGATION 





Bus LLR[ Init ]. output ( Bus LLR[ Init ]. Initial State) 

= Init; 

% 

Mapped- 

axiom TCC generated (at line 

14, column 

12) 

for 


% Bus 

_HLR[ Init] 





% 

{{ State := Bus LLR. State, 





% 

Initial State := Bus LLR. 

Initial State, 



% 

next state := Bus LLR. next state. 




% 

output := Bus LLR. output 

}} 




% proved - complete 




IMP_Bus_HLR_HLR2_TCCl : OBLIGATION 





FORALL 

(s: State [Init], i: bool): 





Bus LLR[ Init ]. output ( Bus LLR[Init] 

.next state(s. 

i) ) = i; 


Figure 11 -TCCs Generated from Theory Interpretation for the Synchronous Bus 

In this way, we have shown that at least one concrete implementation of the BusHLR theory 
exists and that the axioms of the Bus HLR are consistent, allowing us to safely use it as the high- 
level functional requirements for the synchronous bus. The Bus LLR theory can be used as the 
low-level requirements for the bus or a more detailed set of low-level requirements can be 
developed and proven to implement the high-level requirements. 


3.3.3 High-level Requirements for the Synchronous FGS Side 

In this section we develop the high-level requirements for the synchronous FGS side just as we 
did for the synchronous bus. For the synchronous system, each side executes the simple state 
machine shown in Figure 12 to determine which side is the current pilot flying side. 
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Figure 12 - Synchronous Pilot Flying Side Logic 

If a side believes itself to be the Not_Pilot_Flying side, it will become the Pilot_Flying side 
when it sees the Transfer Switch pressed (i.e. a rising edge). If a side is the Pilot_Flying side, it 
will become the Not_Pilot_Flying side when it sees the other side become the pilot flying side. 
Thus, it is always the Not Pilot Flying side that responds to the Transfer Switch, and the current 
Pilot_Flying side always yields when it sees the other side become the Pilot Flying side. The 
PVS specification of the high-level requirements for a synchronous FGS side is shown in Figure 
13 and Figure 14. 

The theory is parameterized with whether this side is the Primary Side. Just as with the bus, we 
introduce an uninterpreted State type, an uninterpreted Initial _State constant and an 
uninterpreted next_state function. Since each side needs to be able to observe a rising edge of the 
Transfer _Switch and of the other side’s PilotFlying value, each side saves the previous value of 
the Transfer Switch and the other side’s Pilot Flying value passed across the bus. 
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Side_HLR[Primary_Side : bool] : THEORY 
BEGIN 

% 

% State defined as an uninterpreted, non-empty type 

% 

State: TYPE+ 

Initial_State : State 

% 

% Next state defined as an uninterpreted function 

% 

next_state: [State, bool, bool -> State] 

% 

% Extractor functions for this side 

% 

pre_TS : [State -> bool] 

pre_OSPF : [State -> bool] 

% 

% Pilot flying output for this side 

% 

pilot_f lying : [State -> bool] 

% 

% Auxiliary definitions for stating axioms 

% 

rise_ospf ( s : State , ospf: bool) : bool = NOT pre_OSPF(s) AND ospf 
rise_ts (s:State, ts :bool) : bool = NOT pre_TS (s) AND ts 


Figure 13 - High-Level Requirements for the Synchronous Side (Part 1) 

We specify uninterpreted extractor functions preJTS and preOSPF that extract these values 
from the side’s state. We also define an extractor pilot Jiving for the single output of the side. To 
provide a convenient shorthand for writing axioms, we also define (interpreted) auxiliary 
functions rise ospf and risejs as shown. The completion of the theory is shown in Figure 14 
where the axioms specifying the side’s required behavior are given. 
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% High level requirements 

CL 


HLR1 : AXIOM 

pilot flying( Initial_State) = Primary_Side 

HLR2 : AXIOM 

pre_TS ( Initial_State ) 

HLR3 : AXIOM 

pre_OSPF( Initial_State) = NOT Primary_Side 
HLR4 : AXIOM 

forall (s:State, ts, ospf : bool) : 

pilot_f lying( s ) AND rise_ospf(s, ospf) => 

NOT pilot _f lying ( next_state ( s, ts, ospf)) 

HLR5 : AXIOM 

forall (s:State, ts, ospf: bool) : 

pilot_f lying( s ) AND NOT rise_ospf(s, ospf) => 
pilot_f lying ( next_state ( s, ts, ospf)) 

HLR6 : AXIOM 

forall (s:State, ts, ospf: bool) : 

NOT pilot_f lying( s ) AND rise_ts(s, ts) => 
pilot_f lying ( next_state ( s, ts, ospf)) 

HLR7 : AXIOM 

forall (s:State, ts, ospf: bool) : 

NOT pilot_f lying( s ) AND NOT rise_ts(s, ts) => 
NOT pilot_f lying ( next_state ( s, ts, ospf)) 

HLR8 : AXIOM 

forall (s:State, ts, ospf: bool) : 

pre_TS ( next_state ( s , ts, ospf)) = ts 

HLR9 : AXIOM 

forall (s:State, ts, ospf: bool) : 

pre_OSPF ( next_state ( s , ts, ospf)) = ospf 

END Side HLR 


Figure 14 - High-Level Requirements for the Synchronous Side (Part 2) 

Axioms HLR1 through HLR3 define the result of applying each of the three extractors to the 
Initial State constructor. HLR4 through HLR7 define the result of applying the pilot Jiving 
extractor to the next_state constructor. HLR4 defines the case when this side is the pilot flying 
side and the other side is observed to become the pilot flying side. 3 HLR5 defines the case where 


The “=>” operator is the implication operator (read “A implies B”), where A — > B states that if A is true, B must 
also be true. It is logically equivalent to not A or B. 
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this side is the pilot flying side and the other side is not observed to become the pilot flying side. 
HLR 6 and HLR7 define the two cases when this side is not the pilot flying side. Note that 
axioms HLR4 through HLR7 are disjoint in that only one of their antecedents can be true at a 
time. Finally, HLR8 and HLR9 define the effect of applying the pre TS and preOSPF 
extractors to the next_state constructor. 

3.3.4 Low-level Requirements for the Synchronous FGS Side 

In this section, we show that the axioms of Section 3.3.3 are consistent by developing a 
constructive implementation of the synchronous FGS side and proving that it satisfies these 
axioms. The PVS theory Side LLR shown in Figure 15 and Figure 16 defines a constructive 
implementation of a synchronous Side by providing a concrete interpretation for each type, 
constant, and function. 

Just as for the high-level requirements, the theory is parameterized with whether it is the 
Primary Side. The two possible values of the state machine of Figure 12, Pilot_Flying and 
Not_Pilot_Flying, are specified as the PVS enumeration type Pilot_Flying_Side. The 
Initial Pilot Flying Side is a constant whose value is determined by the Primary Side theory 
parameter 

The State of a side is stored in a PVS record structure consisting of three fields - the current 
value of the Pilot FlyingJSide state machine (st), the previous value of Transfer Switch (prejts), 
and the previous value of Other _Side_Pilot_Flying input (pre_ospf). The last two values are used 
in the next state function to determine whether a rising edge of the Transfer Switch or the other 
side’s pilot flying output has occurred. The initial value of pre_ts is set to true to ensure that a 
rising edge of the Transfer Switch is not detected in the initial state. The initial value of pre_ospf 
is set to match the initial value of the pilot flying output from the other side. 
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Side_LLR[ Primary_Side : bool] : THEORY 
BEGIN 

% 

% Pilot flying state machine values 

% 

Pilot_Flying_Side : TYPE = {PilotFlying, NotPilotFlying} 

Initial_Pilot_Flying_Side : Pilot_Flying_Side = 

IF Primary_Side THEN PilotFlying 
ELSE NotPilotFlying ENDIF 

% 

% Definition of state and initial state for this side 

% 

State :TYPE+ = [# st : Pilot_Flying_Side , 

pre_ts : bool, 

pre_ospf : bool #] 

Initial_State : State = (# st := Initial_Pilot_Flying_Side , 

pre_ts := TRUE, 

pre_ospf := NOT Primary_Side #) 

% 

% Extractor functions for this side 

% 

pre_TS (s: State) : bool = pre_ts(s) 
pre_OSPF(s: State) : bool = pre_ospf(s) 

% 

% Auxiliary functions for defining next state function 

% 

rise_ts (s:State, ts : bool) : bool = NOT pre_ts (s) AND ts 
rise_ospf ( s : State , ospf : bool) : bool = NOT pre ospf ( s ) AND ospf 


Figure 15 - Low-Level Requirements for the Synchronous Side (Part 1) 

To maintain consistency with the high-level requirements, extractor functions pre TS and 
pre OSPF are defined that simply extract the relevant fields from the state record. Auxiliary 
functions risejs and rise_ospf are also defined to simplify defining the next_state function. The 
next_state function (shown in Figure 16) computes the next state of a side given its current state 
and inputs. 

The next state is computed by first computing the next Pilot_Flying_Side value next _pfs. For 
example, transition 1 is taken if the Pilot Flying Side of the current state, st(s), is Pilot _Flying 
and the other side is observed to become the pilot flying side, setting next _pfs to 
Not Pilot _Flying. In similar fashion, if the Transfer JSwitch is pressed while this side is the 
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Not_Pilot_Flying side, transition 2 is taken setting next _pfs to Pilot_Flying. If neither transition 
is taken, next _pfs is left unchanged as st(s). The next state is then composed from the computed 
value of next _pfs and current input values of the Transfer Switch and Other _Side_Pilot Flying. 


% 

% Next state function 

% 

next_state(s: State, ts:bool, ospfrbool) : State = 

LET 

next_pfs = 

% 

% Transition 1 - Other side becomes the pilot flying side 

% 

IF PilotFlying? ( st ( s ) ) AND rise_ospf(s, ospf) 

THEN NotPilotF lying 

% 

% Transition 2 - Transfer switch is pressed 

% 

ELSIF NotPilotF lying? ( st ( s ) ) AND rise_ts ( s , ts ) 

THEN PilotFlying 

% 

% No transition taken 

% 

ELSE 

st ( s ) 

ENDIF 

IN (# st:= next_pfs, pre_ts := ts, pre_ospf := ospf #) 

% 

% Pilot flying output 

% 

pilot_f lying( s : State) :bool = PilotFlying? ( st ( s ) ) 

END Side LLR 


Figure 16 - Low-Level Requirements for the Synchronous Side (Part 2) 

Finally, the output function extracts a Boolean value from the current state indicating if this side 
believes it is the pilot flying side. 

Just as for the synchronous bus, we prove that the low-level requirements of Figure 15 and 
Figure 16 implement the high-level requirements of Figure 13 and Figure 14 by defining a theory 
interpretation of the high-level requirements based on the low-level requirements. This is shown 
in Figure 17. 
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Side Interpretation [ Primary Side : 
BEGIN 

bool] : THEORY 

o 

% Import low-level requirements (LLR) for a side 

IMPORTING Side_LLR[Primary_Side] 

% Import high-level (HLR) requirements for a side and 

% define the LLR as an interpretation of the HLR 

o 

IMPORTING Side_HLR[Primary_Side] 

{{ 

State 

= Side LLR. State, 

Initial State 

= Side LLR. Initial State, 

next state 

= Side LLR. next state. 

pre_TS 

= Side LLR.pre TS , 

pre_OSPF 

= Side LLR.pre OSPF, 

pilot flying 

}} 

END Side Interpretation 

= Side LLR. pilot flying 


Figure 17 - Theory Interpretation for the Synchronous Side 

When this theory is typechecked using PVS, it generates nine TCCs, one for each axiom 
specified in the high-level requirements shown in Figure 14. These TCCS are easily proven 
using the typecheck-prove (M-x tcp) command of PVS, proving that the Side_LLR requirements 
are an implementation of the SideHLR requirements and that the axioms of the SideHLR 
requirements are consistent. Just as for the synchronous bus, the SideLLR theory can be used as 
the low-level requirements for the side or a more detailed set of low-level requirements can be 
developed and proven to satisfy the Side HLR requirements. 
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3.3.5 PVS Specification of the Synchronous Pilot Flying System 

The PVS specification for the entire synchronous Pilot_Flying_System of Figure 7 is shown in 
Figure 18 and Figure 19. 


Pilot_Flying_System : THEORY 
BEGIN 

% 

% Importing the sytem componenets 

% 

IMPORTING Side_HLR [TRUE] AS Left_Side; 

IMPORTING Bus_HLR [TRUE] AS LRBus ; 

IMPORTING Side_HLR [FALSE] AS Right_Side; 

IMPORTING Bus_HLR [FALSE] AS RLBus ; 

% 

% Defining the system state 

% 

State : Type = [# Left_Side : Left_Side . State , 

LRBus : LRBus . State , 

Right_Side : Right_Side . State , 
RLBus : RLBus . State , 

pre_TS : bool #] 


% 

% Defining the initial system state 

% 

Initial_State : State = (# Left_Side 

LRBus 

Right_Side 

RLBus 

pre_TS 


= Lef t_Side . Initial_State , 

= LRBus . Initial_State , 

= Right_Side . Initial_State , 
= RLBus . Initial_State , 

= TRUE # ) 


Figure 18 - PVS Specification of the Synchronous Pilot Flying System (Part 1) 

The theory begins by importing the four components instantiated with the appropriate 
parameters. The Left_Side is instantiated with the Primary Side parameter set to true and the 
Right Side set to false. The LR Bus is initiated with its initial output set to true to match the 
initial output of the Left_Side and the RL Bus is instantiated with its output set to false to match 
the initial output Right Side. The internal State of the system is defined to be a record structure 
containing the internal state of each of its four components and the previous value of the Transfer 
Switch. The Initial State of the system is simply a record containing the initial state of each 
component with the previous value of the Transfer Switch initialized to true. 

The next_state function for the system shown in Figure 19 merits careful examination. As shown 
in Figure 7, the Left_Side provides an input to the LR Bus which provides an input to the 


45 




RightJSide which provides an input to the RLBus which provides an input to Left_Side. This 
circular dependency (also known as an algebraic loop) is only possible if some component 
depends only on the previous value of its predecessor. Like an Escher print (e.g. Relativity) [4], a 
circular dependency in which every component depends on the current value of its predecessor is 
an illusion that cannot be implemented. 


% 

% Next state function 

% 

next_state ( s : State, TS: bool): State = 

LET 

% 

% Compute next state of LR Bus and Right Side 

% 

Cl = Left_Side . Pilot_f lying ( Left_Side ( s )) , 

next_LR = LRBus . next_state ( LRBus ( s ) , Cl), 

C2 = LRBus . output ( next_LR) , 

next_RS = Right_Side . next_state ( Right_Side ( s ) , TS, C2 ) , 

% 

% Compute next state of RL Bus and Left Side 

% 

C3 = Right_Side. Pilot_f lying ( Right_Side ( s )) , 

next_RL = RLBus . next_state ( RLBus ( s ) , C3), 

C4 = RLBus . output ( next_RL ) , 

next_LS = Lef t_Side . next_state ( Lef t_Side ( s ) , TS, C4) 

IN 

(# Left_Side := next_LS, 

LRBus := next_LR, 

Right_Side := nextRS, 

RLBus := nextRL, 

pre_TS := TS #) 

% 

% Outputs of the system 

% 

Lef t Pilot_Flying_Side ( s : State) : bool = pilot_f lying ( Lef t_Side ( s ) ) 

Right_Pilot_Flying_Side ( s : State): bool = pilot_f lying ( Right_Side ( s ) ) 

END Pilot_Flying_System 


Figure 19 - PVS Specification of the Synchronous Pilot Flying System (Part 2) 

We choose to resolve this cyclic dependency by having each bus read the current value of its 
input (i.e. the previous value fonn the side inputting to the bus) and have each side read the new 
value computed by its inputting bus. The next _st ate function of Figure 19 defines this precisely. 
It states that output of the Left_Side in the current state (Cl) is used as an input in computing the 
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next state of the LRBus. The output of the LRBus after its state is updated (C2) is then used in 
computing the next state of the Left_Side. In similar fashion, the output of the Right Side in the 
current state (C3) is used as an input in computing the next state of the RLBus. The output of 
the RL Bus after its state is updated (C4) is then used in computing the next state of the 
Right Side. The next state of the entire system is composed from the new state computed for 
each component and by updating the previous value of the Transfer Switch. 

Finally, the theory defines the two outputs of the Pilot Flying system, the Boolean functions 
Left_Pilot_Flying_Side and Right_Pilot_Flying_Side indicating whether each side believes it is 
the pilot flying side. 
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3.3.6 Formal Verification of the Synchronous Pilot Flying Example 

This section shows that the system architecture and high-level component requirements comply 
with the system requirements by proving that the five system requirements are satisfied by the 
system design and high-level requirements for each component. Stated informally, the five 
system requirements are: 

R1 . At least one side shall be the pilot flying side. 

R2. At most one side shall be the pilot flying side. 

R3. Pressing the Transfer Switch shall always change the pilot flying side. 

R4. The system shall start with the Primary Side as the pilot flying side. 

R5. The system shall not change the pilot flying side unless the Transfer Switch is pressed. 

The first requirement R1 can be stated formally in PVS as shown in Figure 20. 

s: VAR Pilot_Flying_System. State 

R1 : THEOREM 

Lef t_Pilot_Flying_Side ( s ) or Right_Pilot_Flying_Side ( s ) 

Figure 20 - Incorrect Statement of Synchronous Requirement R1 in PVS 

Unfortunately, this property cannot be proven. This is because the type State does not explicitly 
exclude system states where neither side is the pilot flying side. However, for our system the 
only states of interest are those that can be reached in some number of steps from the Initial 
State. The step in proving requirement R1 is restating it so that it only applies to reachable states. 
The first part of the Pilot Flying _Sy stem -Requirements theory shown in Figure 21 defines what 
it means for a state to be reachable. 
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Pilot_Flying_System_Requirements : THEORY 
BEGIN 

IMPORTING Pilot_Flying_System 

s: VAR Pilot_Flying_System. State 

ts: VAR bool 

% 

% Definition of a reachable state 

% 

Reachable_State ( s ) : INDUCTIVE bool = 
s = Initial_State OR 

(EXISTS (r: Pilot_Flying_System. State, t: bool) : 

Reachable_State ( r ) AND s = next_state ( r , t ) ) 

% 

% Definition of a valid state 

% 

Pre_TS_Consistency ( s ) : bool = 

pre_TS ( Lef t_Side ( s ) ) = pre_TS ( s ) and 

pre_TS ( Right_Side ( s ) ) = pre_TS(s) 

Pre_OSPF_Consistency ( s ) : bool = 

pre_OSPF ( Right_Side ( s ) ) = LRBus . output ( LRBus ( s ) ) and 
pre_OSPF ( Lef t_Side ( s ) ) = RLBus . output ( RLBus ( s ) ) 

At Least_One_Side_Flying ( s ) : bool = 

Lef t_Pilot_Flying_Side ( s ) OR Right Pilot_Flying_Side ( s ) 

Buses_Dif f er_When_Sides_Same ( s ) : bool = 

pilot_f lying ( Lef t_Side ( s ) ) = pilot flying ( Right_Side ( s ) ) => 
LRBus . output ( LRBus ( s ) ) /= RLBus . output ( RLBus ( s ) ) 

ValidState ( s ) : bool = 

At Least_One_Side_Flying ( s ) AND 
Pre_TS_Consistency ( s ) AND 
Pre_OSPF_Consistency ( s ) AND 
Buses_Dif f er_When_Sides_Same ( s ) 

% 

% Proof that every reachable state is a valid state 

% 

Reachable_States_Valid : THEOREM 

Reachable_State ( s ) => Valid_State ( s ) 


Figure 21 - Synchronous Pilot Flying System Requirements (Part 1) 

The predicate Reachable States in Figure 21 inductively defines a reachable state to be either the 
Initial State or any state that can be reached through application of the next_state function from 
a reachable state. With this definition, we can restate the theorem for requirement R1 as shown in 
Figure 22. 
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R1 : THEOREM 

Reachable_State ( s ) => 

Lef t Pilot_Flying_Side ( s ) or Right_Pilot_Flying_Side ( s ) 

Figure 22 - Correct Statement of Requirement R1 in PVS 

This theorem can be proven, but the proof is complicated and it needs to be repeated in proving 
the other requirements. To keep our proofs manageable, we first shall define a set of predicates 
describing the relationships between the system components that the system will maintain during 
its execution and then prove that those predicates are true of every reachable state. 

The PreTS 'Consistency predicate of Figure 21 states that the previous value of the Transfer 
Switch stored in the left and right sides must be the same as that stored in the system state. The 
Pre OSPF Consistency predicate states that the previous value of the other side’s pilot flying 
indication stored in each side {preOSPF) agrees with the output of the bus that passed it that 
value. The At_Least_One_Side_Flying predicate states that at least one side is the pilot flying 
side. The Buses_Differ_When_Both_Sides_Flying predicate states that when both sides are the 
pilot flying side, the buses must contain different Boolean values. These predicates are collected 
together as a single conjunction in the VaIid_State predicate shown in Figure 21. 

Since Valid_State contains many of the relationships between system components necessary to 
prove the system requirements and since it is not defined recursively, it is much easier to use in 
the proofs than Reachable _States. Unfortunately, development of the Valid_State predicate is not 
always obvious. Some of the constraints, such as At_Least_One_Side_Flying and 
Pre TS Consistency are intuitive. The others were developed by trying to prove the system 
requirements and carefully studying the proof obligations produced by PVS. For example, the 
Buses _Differ_When_Both_Sides_Flying predicate is not obvious and was added in the process of 
proving requirements R1 through R5. However, in retrospect it is clear that if it were not true, the 
system would either deadlock with both sides as the pilot flying side or immediately transition to 
a state where neither side is the pilot flying side. 

The next step is to prove that every reachable state is also a valid state. The 
Reachable _States_Valid theorem is stated at the bottom of Figure 21 and its proof is shown in 
Figure 23. 
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; ; ; Proof Reachable_States_Valid-2 for formula 
Pilot_Flying_System_Requirements . Reachable_States_Valid 
; ; ; developed with shostak decision procedures 

| II II 

(auto-rewrite-theories "Left_Side" "LRBus" "Right_Side" "RLBus") 
(rule-induct "Reachable_State " ) 

( skosimp ) 

(case "s!2 = Initial_State " ) 

(("1" (grind)) 

(" 2 " 

( assert ) 

(hide 1) 

( grind ) 

(("1" 

(case "Right_Side . pi lotf lying ( Right_Side ( r ! 1 ) ) " ) 

(("1" (grind)) ("2" (grind)))) 

("2" 

(case "Right_Side . pi lotf lying ( Right_Side ( r ! 1 ) ) " ) 

(("1" (grind)) ("2" (grind)))) 

(" 3 " 

(case "Lef t_Side . pi lot_f lying ( Lef t_Side ( r ! 1 ) ) " ) 

(("1" (grind)) ("2" (grind)))) 

( " 4 " 

(case "Lef t_Side . pi lot_f lying ( Lef t_Side ( r ! 1 ) ) " ) 

(("1" (grind)) ("2" (grind)))))))) 


Figure 23 - PVS Proof of Synchronous Reachable States Valid Theorem 

The auto-rewrite-theories command installs the axioms stated in the high-level requirements for 
each side and each bus as automatic rewrite rules. The rule-induct command adds the inductive 
definition of Reachable _States to the proof tree as the rule shown in Figure 24. 


FORALL ( s ) : 

(s = Initial_State OR 

(EXISTS (r: Pilot_Flying_System. State, t: bool): 
ValidState ( r ) AND s = next_state ( r , t))) 
IMPLIES ValidState ( s ) 


Figure 24 - Inductive Sequent for Reachable States 

The skosimp command replaces the universal quantification over s with an unspecified constant 
s!2 and simplifies the proof obligation. The case command splits the proof into two sub-goals. 
The first sub-goal, in which s!2 is the Initial State, is easily discharged with the PVS grind 
command. The second sub-goal, in which s!2 is any state other than the Initial State, is reduced 
through application of the assert, hide, and grind commands to four sub-goals. Each of these can 
be discharged by case splitting on the value of the Pilot_Flying output of either the left or right 
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side of state r!l (introduced by the grind command to instantiate the existential quantification 
over r) followed by application of grind to each of the two resulting sub-goals. 

With the proof that every reachable state is a valid state, the proof of requirements R1 through 
R5 is straightforward. The formal statement of requirements R1 and R2 are shown in Figure 25. 

To make the requirements more readable, we define two predicates over the system state. The 
predicate switching sides identifies the system states in which the system is in the process of 
changing the pilot flying side, i.e. where one side has become the pilot flying side but that 
change has not reached the other side. The predicate pressed provides a convenient way of 
identifying a rising edge of the Transfer Switch. 


% 

% The Transfer Switch is pressed in state s when its value rises. 

% 

pressed (ts, s) : bool = not pre_TS ( s ) and ts 

% 

% The system is switching sides when either side has become the 
% pilot flying side and that change has not reached the other side 

% 

switching_sides ( s ) : bool = 

pilot flying ( Left_Side ( s ) ) AND NOT output ( LRBus ( s ) ) OR 
pilot flying ( Right_Side ( s ) ) AND NOT output ( RLBus ( s ) ) 

% 

% R1 . At least one side shall be the pilot flying side. 

% 

R1 : THEOREM 

Reachable_State ( s ) => 

Lef t_Pilot_Flying_Side ( s ) or Right_Pilot_Flying_Side ( s ) 

% 

% R2 . At most one side shall be the pilot flying side 
% except while the system is switching sides. 

% 

R2 : THEOREM 

Reachable_State ( s ) AND NOT switching_sides ( s ) => 

Lef t_Pilot_Flying_Side ( s ) /= Right_Pilot_Flying_Side ( s ) 


Figure 25 - Synchronous Pilot Flying System Requirements (Part 2) 

The proof of requirement R1 is shown in Figure 26. 
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;;; Proof Rl-1 for formula Pilot_Flying_System_Requirements . R1 
; ; ; developed with shostak decision procedures 
("" (use "Reachable_States_Valid" ) (grind)) 


Figure 26 - PVS Proof of Requirement R1 for Synchronous Pilot Flying System 

The proof of R1 is immediate since all of the real work was done in proving that every reachable 
state is a valid state. The proof invokes the Reachable _States_Valid theorem with the PVS use 
command followed by a PVS grind command. 

Trying to prove requirement R2 (at most one side shall be the pilot flying side) reveals that this 
requirement cannot hold for all reachable states. In particular, in a state in which one side has 
just become the pilot flying side but this infonnation has not been transmitted to the other side, 
both sides will be the pilot flying side for one step. However, a safety analysis shows that it is 
acceptable to have both sides be the pilot flying side for a single step and we modify R2 to be 
required for only reachable states while the system is not switching sides. Requirement R2 can 
be proven with the same proof shown in Figure 26 used to prove requirement Rl. 
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% 

% R3 . Pressing the Transfer Switch shall always change pilot 
% pilot flying side. 

% 

R3a : THEOREM 

Reachable_State ( s ) => 

(not Lef t_Pilot_JFlying_Side ( s ) and pressed ( ts , s ) => 

Lef t_Pilot_Flying_Side ( next_state ( s , ts ) ) ) 

R3b : THEOREM 

Reachable_State ( s ) => 

(not Right_Pilot_Flying_Side ( s ) and pressed ( ts , s ) => 
Right_Pilot_Flying_Side ( next_state ( s , ts ) ) ) 

% 

% R4 . The system shall start with the Primary Side as the pilot 
% flying side. 

% 

R4 : THEOREM 

Lef t Pilot_JFlying_Side ( Initial_State ) 

% 

% R5 . The system shall not change the pilot flying side if it is 
% not switching sides and the Transfer Switch is not pressed. 

% 

R5a : THEOREM 

Reachable_State ( s ) AND 

NOT switching_sides ( s ) AND NOT pressed (ts, s) => 

( Lef t_Pilot_Flying_Side ( next_state ( s , ts)) = 

Lef t_Pilot_Flying_Side ( s ) ) 

R5b : THEOREM 

Reachable_State ( s ) AND 

NOT switching_sides ( s ) AND NOT pressed (ts, s) => 

( Right_Pilot Flying_Side ( next_state ( s , ts)) = 
Right_Pilot_Flying_Side ( s ) ) 

END Pilot_Flying_System_Requirements 


Figure 27 - PVS Specification of the Pilot Flying System Requirements (Part 3) 

Requirement R3 (pressing the Transfer Switch shall always change the pilot flying side) is 
broken down into two smaller requirements. R3a states that for a reachable system state, if the 
left side is not the pilot flying side and the Transfer Switch is pressed, then the left side will 
become the pilot flying side in the next state. R3b states the same property for the right side. 
Both of these requirements can be proven with the proof shown in Figure 28. 
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;;; Proof R3a-1 for formula Pilot_Flying_System_Requirements . R3a 
; ; ; developed with shostak decision procedures 

| II II 

(use "Reachable_States_Valid" ) 

(auto-rewrite-theories "Left_Side" "LRBus” "Right_Side" "RLBus") 
(grind) ) 


Figure 28 - PVS Proof of Requirement R3a/b for Synchronous Pilot Flying System 

This proof first invokes the Reachable _States_VaIid theorem with the PVS use command, then 
installs the axioms stated in the high-level requirements for each side and each bus as automatic 
rewrite rules using the PVS auto-rewrite-theories command, and finally completes the proof 
with a PVS grind command. 

The proof of requirement R4 (the system shall start with the Primary Side as the pilot flying side) 
is equally straightforward. It is discharged by using the auto-rewrite-theories command to install 
the axioms for the high-level requirements as automatic rewrite rules followed by a grind 
command. 

Finally, the proof of requirement R5 (the system shall not change the pilot flying side unless the 
Transfer Switch is pressed) requires a slight modification. First, it is broken down into two 
smaller requirements, R5a and R5b, as was done for requirement R3. Trying to prove these 
reveal that they only hold if the system is not already in the process of switching sides. We revise 
the original requirement to include this caveat as shown in Figure 27. Both requirements can then 
be proven using the same proof used to prove requirements R3a and R3b (Figure 28). 

While this completes the proof of the original five requirements, the current definition of 
Valid_State may not be sufficient to prove additional useful properties about the Pilot Flying 
system. This is because while we proved that every reachable state is a valid state, we have not 
proven that every valid state is reachable. In other words, there may be states that are valid but 
that cannot be reached. In fact this is exactly the situation. The definition of Valid_State does not 
include all the relationships between system components that the system will maintain, ensuring 
that there are valid states that are not reachable. This is demonstrated in the theory 
Pilot_Flying_System_Requirements2 shown in Figure 29. 
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Pilot_Flying_System_Requirements2 : THEORY 
BEGIN 

IMPORTING Pilot_Flying_System_Requirements 

s: VAR Pilot_Flying_System. State 

ts: VAR bool 

% 

% Enhanced definition of a valid state 

% 

At Least_One_Bus_High ( s ) : bool = 

output ( LRBus ( s ) ) OR output ( RLBus ( s ) ) 

Quiescent ( s ) : bool = 

( output ( LRBus ( s ) ) /= output ( RLBus ( s ) ) AND 
pilot_f lying ( Left_Side ( s ) ) /= pilot_f lying ( Right_Side ( s )) ) => 
( output ( LRBus ( s ) ) = pilot_f lying ( Left_Side ( s ) ) AND 
output ( RLBus ( s ) ) = pilot_f lying ( Right_Side ( s )) ) 

Valid_State2 ( s ) : bool = 

Valid State ( s ) AND 
At Least_One_Bus_High ( s ) AND 
Quiescent ( s ) 

% 

% Every reachable state is a valid (2) state 

% 

Reachable_States_Valid2 : THEOREM 

Reachable_State ( s ) => Valid_State2 ( s ) 

% 

% The system only switches sides for one step 

% 

Switching_Transient : THEOREM 

Reachable_State ( s ) AND switching_sides ( s ) => 

NOT switching_sides ( next_state ( s , ts)) 

END Pilot_JFlying_System_Requirements2 


Figure 29 - Pilot Flying System Requirements 2 

This theory imports the Pilot_Flying_System_Requirements theory so that it contains the current 
definition of VaIid_State. It also includes the Switching Transient theorem which states that if 
the system is switching sides in one state, it is not switching sides in the next state. This theorem 
cannot be easily proven using the definition of Valid_State, but it can be proven using the 
definition Valid_State2 that adds two additional constraints to Valid_State. The first, 
At Least One Bus High, states that the output of at least one of the two buses is always true. 
The second, Quiescent, states that in a quiescent state where the output of both sides and both 
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buses differ, the output of the left bus will be equal to the output of the left side and the output of 
the right bus will be equal to the output of the right side. 

It is easily proven that all reachable states are Valid_State2 states using a proof similar to that of 
Figure 23. The Switching Transient theorem is then easily proven using the proof of Figure 30 
which invokes Reachable States Valid2 rather than Reachable States Valid. 


; ; ; Proof Switching Transient-2 for formula 
Pilot_Flying_System_Requirements2 . Switching_Transient 
; ; ; developed with shostak decision procedures 
( " " 

(auto-rewrite-theories "Left_Side" "LRBus" "Right_Side" "RLBus") 
( use "Reachable_States_Valid2 " ) 

(grind) ) 


Figure 30 - PVS Proof of Switching Transient 
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3.4 The Asynchronous Pilot Flying Example 

Designing and verifying the Pilot Flying System is considerably more difficult in the 
asynchronous case when the components are not driven by a single master clock. Values may be 
missed entirely by a component if they arrive while it is not executing, leading to race and 
deadlock conditions. If no assumptions are made about the individual component clocks, the 
Pilot Flying System can be implemented correctly only through the use of a hand-shaking 
protocol. This section describes how the fully asynchronous case can be specified and verified in 
PVS. 

To model asynchrony, we introduce for each component a single Boolean valued clock signal. 
When its clock is true, a component will take a step just as in the synchronous case. When its 
clock is false, the component makes no change to its internal state or outputs. While this model 
assumes an underlying discrete model of time where each component clock can tick only when 
the global clock ticks, we make no other assumptions about the clocks. The global clock may 
tick at any rate and the component clocks may tick or not tick at any time the global clock ticks. 
This model of time is sufficient to generate the conditions we are interested in verifying. The top 
level diagram for the asynchronous Pilot Flying example is shown in Figure 3 1 . 

Left_Pilot_Flying_Side CLK3 



Right_Pilot_Flying_Side 


Figure 31 - Asynchronous Pilot Flying System 

The asynchronous system diagram differs from the synchronous diagram only in the addition of 
the four clocks, CLK1 through CLK4. However, there are several other changes needed to the 
underlying components to produce a correct implementation. These are described in the 
following sections. 
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3.4.1 Specification of the Asynchronous Bus Messages 

To implement the hand-shaking protocol necessary in the asynchronous case, each FGS will 
generate both its pilot flying status and a Boolean acknowledgement. Since these will be 
produced and conveyed across the bus together we define a single Message type as shown Figure 
32. A bus Message is a record type with two fields, pfs for the pilot flying status and ack for the 
acknowledgement. We also define a Msg constructor function which constructs a new message 
from values for pfs and ack. 

Message: THEORY 
BEGIN 

% 

% A bus message consists of the Pilot Flying Status and an Ack 

% 

Message: TYPE = [# pfs: bool, ack :bool #] 

% 

% Message constructor 

% 

Msg(pfs, ack : bool) : Message = (# pfs := pfs, ack := ack #) 

END Message 


Figure 32 - PVS Specification of a Bus Message 

3.4.2 High-Level Requirements for the Asynchronous Bus 

The PVS theory for the high-level requirements for the asynchronous bus is shown in Figure 33. 
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Bus_HLR[ INITPFS : bool, INITACK: bool]: THEORY 
BEGIN 

Importing Message 

% 

% Define the state and initial state 

% 

State: TYPE+ 

Initial_State : State 

% 

% Next state function 

% 

next_state: [State, bool. Message -> State] 

% 

% Output of the bus 

% 

output: [State -> Message] 

% 

% High level requirements 

% 

HLR1 : AXIOM 

output ( Initial_State) = Msg ( INITPFS , INITACK) 
HLR2 : AXIOM 

forall (s: State, elk: bool, input: Message) : 
output ( next_state ( s , elk, input)) = 

IF NOT elk THEN output ( s ) ELSE input ENDIF 

END Bus HLR 


Figure 33 - High-Level Requirements for the Asynchronous Bus 

The theory is parameterized with the INIT_PFS and INIT_ACK values specifying the initial 
output values of the bus. Just as with the high-level requirements for the synchronous bus, 
uninterpreted values are provided for the type State, the Initial State, and the next _s tat e and 
output functions. Two axioms, HR1 and HR2, specify the high level requirements of the bus. 
The other major change from the synchronous case is that HR2 specifies that the output of the 
bus changes only when its clock value is true. 


3.4.3 Low-Level Requirements for the Asynchronous Bus 

The low-level requirements for the asynchronous bus are shown in Figure 34. 
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Bus_LLR [ INITPFS : bool, INITACK: bool]: THEORY 
BEGIN 

Importing Message 

% 

% Define the state and initial state 

% 

State: TYPE+ = Message 

Initial_State: State = Msg ( INITPFS , INITACK) 

% 

% Next state function 

% 

next_state ( s : State, elk: bool, input: Message): State = 
IF NOT elk THEN s ELSE input ENDIF 

% 

% Output of the bus 

% 

output] s: State): Message = s 

END Bus LLR 


Figure 34 - Low-Level Requirements for the Asynchronous Bus 

In the low-level requirements, a concrete interpretation has been assigned to each uninterpreted 
type, constant, and function of the high-level requirements. The type State has been defined to be 
a record structure of the type Message. The Initial _State is a message constructed from the 
theory parameters. The next_state function is defined to return the current state when its clock is 
false and its input message when its clock is true. The output function returns the current state of 
the bus. 

Just as with the synchronous bus, we demonstrate that the axioms of the high-level bus 
requirements are consistent with a theory interpretation as shown in Figure 35. 
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Bus_Interpretation [ INITPFS : bool, INITACK : bool]: THEORY 
BEGIN 

% 

% Import low-level requirements (LLR) for a bus 

% 

IMPORTING Bus_LLR[ INITPFS , INITACK] 

% 

% Import the high-level (HLR) requirements for a bus and 
% define the LLR as an interpretation of the HLR 

% 

IMPORTING Bus_HLR[ INITPFS, INITACK] {{ 

State := Bus_LLR . State , 

Initial_State := Bus_LLR . Initial_State , 

next_state := Bus_LLR . next_state , 

output := Bus_LLR . output 

}} 

END Bus_Interpretation 


Figure 35 - Theory Interpretation for Asynchronous Bus 

Type checking this theory generates two TCCs, both of which are easily proven using the 
typecheck-prove (M-x tcp) command of PVS, proving that the Bus LLR requirements are an 
implementation of the BusHLR requirements and that the axioms of the BusHLR theory are 
consistent. 


3.4.4 High-Level Requirements for the Asynchronous FGS Side 

The PVS specification for an FGS Side also needs to be changed to input and output values of 
type Message rather than just a simple Boolean. Since we make no assumptions about the 
component clocks, a correct implementation of the synchronization logic requires a hand-shaking 
protocol as illustrated in Figure 36. 
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Figure 36 - Asynchronous Pilot Flying Side Logic 

The Ack value is used to communicate to the other side when a side has reached a stable state. 
The Primary _Side starts in the Confirmed sub-state of the Pilot_Flying state with its Ack set to 
true. The other side starts in the Listening sub-state of the Not Pilot _Flying state with its Ack 
also set to true. When the Primary Side sees the other side become the pilot flying side, it 
transitions to the Inhibited sub-state of the Not Pilot Flying state and sets its Ack to false. While 
in the Inhibited state, a side does not respond to the flight crew pressing the Transfer Switch. 4 
The Not_Pilot_Flying_Side resumes listening for the Transfer Switch when it receives an Ack 
from the other side indicating that the other side has reached the Confirmed state. When the 
Transfer Switch is pressed, the Not Pilot Flying side transitions to the Waiting sub-state of the 
Pilot_Flying state and remains in this sub-state until it sees the other side’s Ack fall, indicating 
that the other side has yielded control. The PVS specification for the high-level requirements for 
an asynchronous FGS side is shown in Figure 37, Figure 44, and Figure 45. 


In an actual system, it could be remedied by ensuring the Transfer Switch remains high longer than the time 
needed for the Ack to be received from the new pilot flying side. 
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Side_HLR[Primary_Side : bool] : THEORY 
BEGIN 


IMPORTING Message 

% 

% State defined an an uninterpreted, non-empty type 

% 

State: TYPE+ 


Initial State: State 


% 

% Next state defined as an uninterpreted function 

% 

next_state: [State, bool, bool, Message-> State] 

% 

% Extractor functions for this side 

% 

pre_TS : [State -> bool] 

pre_MSG: [State -> Message] 

% 

% Output is a message containing the pilot flying status and ack 

% 

output : [State -> Message] 


% 

% Auxiliary functions for stating properties 

% 

rise_ts (s: State, ts:bool ): bool = NOT preTS ( s ) AND ts 
rise_ospf(s: State, m:Message): bool = NOT pf s (pre_MSG( s ) ) AND pfs(m) 
fall_ack (s: State, m:Message): bool = ack ( pre_MSG ( s ) ) AND NOT ack(m) 


confirmed ( s : 
inhibited ( s : 
listening ( s : 
waiting (s: 


State): bool = pf s ( output ( s ) ) AND ack ( output ( s ) ) 

State): bool = NOT pf s ( output ( s ) ) AND NOT ack ( output ( s ) ) 

State): bool = NOT pf s ( output ( s ) ) AND ack ( output ( s ) ) 

State): bool = pf s ( output ( s ) ) and NOT ack ( output ( s ) ) 


Figure 37 - High-Level Requirements for the Asynchronous Side (Part 1) 

The Side HLR theory is parameterized with whether this side is the Primary Side. Uninterpreted 
values are provided for the type Side, the constant Initial State, the next _s tat e function, and 
extractor functions for the previous value of the Transfer Switch (pre_TS), the previous value of 
the other side’s message, (pre_MSG), and the output of this side. We also specify several 
convenient auxiliary functions. The functions risejs, rise_ospf and fall_ack define precisely 
how a rising edge of the Transfer Switch, a rising edge of the other side’s pilot flying value, and 


64 




a falling edge of the other side’s ack are to be identified. The functions confirmed, inhibited, 
listening, and waiting provide a convenient way identifying the sub-state of a side. 


% 

% High level requirements 

% 

HLR1 : AXIOM 

output ( Initial_State ) = Msg ( Primary_Side , TRUE) 

HLR2 : AXIOM 

pre TS ( Initial_State ) 

HLR3 : AXIOM 

pre_MSG ( Initial_State ) = Msg (NOT Primary_Side , TRUE) 


Figure 38 - High-Level Requirements for the Asynchronous Side (Part 2) 

Axioms HLR1 through HLR3 in Figure 38 define the result of applying each of the three 
extractors to the Initial State constructor. The output of the Initial _State is set to either 
confirmed or listening depending on the Primary Side theory parameter. The stored value of the 
Transfer Switch is initialized to true so that it cannot be pressed in the initial step. The stored 
value of the other side’s message is initialized to agree with the initial output of the bus from the 
other side 
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HLR4 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m:Message) : 

NOT elk => output ( next_state ( s , elk, ts, m) ) = output(s) 

HLR5 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: Message) : 
elk AND confirmed(s) AND rise_ospf(s, m) => 
inhibited ( next_state ( s , elk, ts, m) ) 


HLR6 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: Message) : 
elk AND confirmed(s) AND NOT rise_ospf(s, m) => 
confirmed (next_state( s, elk, ts, m) ) 


HLR7 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: 
elk AND inhibited(s) AND ack(m) => 
listening ( next_state ( s , elk, ts. 


Message) : 
m) ) 


HLR8 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: 
elk AND inhibited(s) AND NOT ack(m) 
inhibited ( next_state ( s , elk, ts. 


Message) : 
=> 


m) ) 


HLR9 : AXIOM 

FORALL (s:State, elk: bool, 
elk AND listening(s) AND 
waiting ( next_state ( s , 


ts:bool, m: Message) : 
rise_ts(s, ts) => 
elk , ts , m) ) 


HLR10 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: Message) : 
elk AND listening(s) AND NOT rise_ts(s, ts) => 
listening ( next_state ( s , elk, ts, m) ) 


HLR11: AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: Message) : 
elk AND waiting(s) AND fall_ack(s, m) => 
confirmed (next_state( s, elk, ts, m) ) 


HLR12 : AXIOM 

FORALL (s:State, elk: bool, ts:bool, m: Message) : 
elk AND waiting(s) AND NOT fall_ack(s, m) => 
waiting ( next_state ( s , elk, ts, m) ) 


Figure 39 - High-Level Requirements for the Asynchronous Side (Part 3) 

HLR4 through HLR12 in Figure 39 define the result of applying the output extractor to the 
next_state constructor in accordance with the protocol of Figure 36 (recall that confirmed, 
inhibited, listening, and waiting are defined in terms of the output extractor). Note that HLR4 
asserts that if the clock for a side is false, no change occurs in the output of the side. 
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HLR13 : AXIOM 





FORALL (s:State, elk: bool, 

ts : 

bool, m: 

Message ) 

: 

NOT elk => pre TS(next 

state(s, elk, 

ts , m) ) = 

pre_TS ( s ) 

HLR14 : AXIOM 





FORALL (s:State, elk: bool, 

ts : 

bool, m: 

Message ) 

: 

elk => pre TS(next state(s. 

elk, ts. 

m) ) = ts 


HLR15 : AXIOM 





FORALL (s:State, elk: bool, 

ts : 

bool, m: 

Message ) 

: 

NOT elk => pre MSG (next 

state(s, elk 

, ts, m) ) 

= pre_MSG ( s ) 

HLR16 : AXIOM 





forall (s:State, clkrbool, 

ts : 

bool, m: 

Message ) 

: 

elk => pre MSG (next state (s 

, elk, ts 

, m) ) = m 


END Side_HLR 






Figure 40 - High-Level Requirements for the Asynchronous Side (Part 4) 

Finally, HLR13 through HLR16 define the result of applying the extractors pre_TS and 
pre_MSG to the constructor next_state. Again, if the clock for the side if false, the value 
returned by each extractors is not changed by the next_state function. 


3.4.5 Low-Level Requirements for the Asynchronous FGS Side 

The PVS theory Side LLR shown in Figure 41 and Figure 42 defines a constructive 
implementation of a synchronous Side by providing a concrete interpretation for each type, 
constant, and function. The four possible values of the state machine of Figure 36, Confirmed, 
Inhibited, Listening, and Waiting, are defined as the PVS enumeration type Pilot_FIying_Side. 
The initial value of the state machine is defined to be either Confirmed or Listening depending on 
the Primary Side theory parameter. 

The State of a side is defined as a PVS record structure consisting of the three fields - the current 
value of the Pilot _Flying_Side state machine (st), the previous value of the Transfer Switch 
{pre_ts), and the previous value of the bus message from the other side (prejnsg). The 
Initial State constant consists of a record in which the st component is set the 
Initial Pilot Flying Side, the pre_ts component is initialized to true to ensure the Transfer 
Switch cannot be pressed in the initial state, and the prejnsg component is set to agree with the 
message provided by the bus from the other side. 
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Side_LLR[ Primary_Side : bool] : THEORY 
BEGIN 

IMPORTING Message 

% 

% Pilot flying state machine values 

% 

Pilot_Flying_Side : TYPE = {Confirmed, Inhibited, Listening, Waiting} 

Initial_Pilot_Flying_Side : Pilot_Flying_Side = 

IF Primary_Side THEN Confirmed ELSE Listening ENDIF 


% 

% Definition of state and initial state for this side 

% 

State: TYPE = [# st : Pilot_Flying_Side , 

pre_ts : bool, 
pre_msg : Message #] 


Initial State: State 


(# st 

pre_ts 

pre_msg 


= Initial_Pilot_Flying_Side , 

= TRUE, 

= Msg ( NOT Primary_Side, TRUE) #) 


% 

% Extractor functions for this side 

% 

pre_TS (s: State): bool = pre_ts(s) 

pre_MSG(s: State): Message = premsg(s) 

% 

% Auxiliary functions for defining next state function 

% 

rise_ospf ( s : State , m:Message): bool = NOT pf s ( pre_MSG ( s ) ) AND pfs(m) 
rise_ts (s:State, ts:bool ): bool = NOT pre_TS ( s ) AND ts 
fallack (s:State, m:Message): bool = ack ( pre_MSG ( s ) ) AND NOT ack(m) 


Figure 41 - Low-Level Requirements for the Asynchronous Side (Part 1) 

To maintain consistency with the high-level requirements, extractor functions pre TS and 
pre_MSG are defined. Auxiliary functions are also defined to simplify specification of the 
next state function. 
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% 

% Next state function 

% 

next_state(s: State, elk: bool, ts: bool, m: Message): State = 

% 

% No change when clock is false 

% 

IF (NOT elk) THEN 
s 

ELSE LET 

next_st = 

% 

% Transition 1 - Rise of Other Side Pilot Flying 

% 

IF ( Confirmed? ( st ( s ) ) AND rise ospf(s, m) ) 

THEN Inhibited 

% 

% Transition 2 - Rise of Other Side Pilot Flying 

% 

ELSIF ( Inhibited? ( st( s) ) AND ack(m)) 

THEN Listening 

% 

% Transition 3 - Rise of Transfer Switch 

% 

ELSIF ( Listening? ( st ( s ) ) AND rise_ts(s, ts)) 

THEN Waiting 

% 

% Transition 4 - Fall of Other Side Ack 

% 

ELSIF (Waiting? ( st ( s ) ) AND fall_ack(s, m) ) 

THEN Confirmed 

% 

% No transition taken 

% 

ELSE 
st ( s ) 

ENDIF 

IN 

(# st := next_st, pre_ts := ts, pre_msg := m #) 

ENDIF 

% 

% Output is a message containing the pilot flying status and the ack 

% 

output ( s : State ) : Message = 

(# pfs := Conf irmed? ( st ( s ) ) OR Waiting? ( st ( s )) , 

ack := Conf irmed? ( st ( s ) ) OR Listening? ( st ( s ) ) #) 

END Side LLR 


Figure 42 - Low-Level Requirements for the Asynchronous Side (Part 2) 

The next_state function (Figure 42) computes each of the three components of the next system 
state from the current state and inputs, where the inputs consist of the side’s clock, the Transfer 
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Switch, and the bus message from the other side. If the side’s clock is false, no change occurs in 
the side’s state. Otherwise, the next sub-state is computed in accordance with the logic of Figure 
36 and composed with the current value of the Transfer Switch and the message from the other 
side. 

To show that the low-level requirements of Figure 41 and Figure 42 implement the high-level 
requirements of Figure 37 through Figure 40, we define a theory interpretation as shown in 
Figure 43. 


Side Interpretation [ Primary Side: bool]: THEORY 

BEGIN 


% 

% Import the low-level requirements ( LLR ) for a side 

IMPORTING Side_LLR[ Primary_Side ] 


% 

% Import the high-level (HLR) requirements for a side and 
% define the LLR as an interpretation of the HLR 

a 

IMPORTING Side_HLR[ Primary_Side ] 

{{ 

State 

= Side LLR. State, 

Initial State 

= Side LLR. Initial State, 

next state 

= Side LLR. next state. 

pre_TS 

= Side LLR.pre TS, 

pre_MSG 

= Side LLR.pre MSG, 

output 

= Side LLR. output 

}} 


END Side Interpretation 



Figure 43 - Theory Interpretation for the Asynchronous Side 

Type checking this theory with PVS generates 16 TCCs, one for each axiom specified in the 
high-level requirements of Figure 37 through Figure 40. These TCCS are easily proven using the 
typecheck-prove (M-x tcp) command of PVS, proving that the Side LLR requirements are an 
implementation of the SideHLR requirements and that the axioms of the SideHLR 
requirements are consistent. 


3.4.6 PVS Specification of the Asynchronous Pilot Flying Example 

The PVS specification for the entire asynchronous Pilot _Flying_System depicted in Figure 31 is 
shown in Figure 44 and Figure 45. 
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Pilot_Flying_System: THEORY 
BEGIN 


% 

% Import the system components 

% 

IMPORTING Side_HLR[ TRUE ] AS Left_Side; 

IMPORTING Bus_HLR [TRUE, TRUE] AS LRBus ; 
IMPORTING Side_HLR[ FALSE] AS Right_Side; 

IMPORTING Bus_HLR [FALSE, TRUE] AS RLBus ; 


% 

% Define the system state 

% 

State: Type = [# Left_Side 

LRBus 

Right_Side 

RLBus 

pre_TS 


Lef t_Side . State , 
LRBus . State , 
Right_Side . State , 
RLBus . State , 
bool 


#] 


% 

% Define the initial system state 

% 

Initial_State : State = (# Left_Side 

LRBus 

Right_Side 

RLBus 

pre_TS 


= Lef t_Side . Initial_State , 

= LRBus . Initial_State , 

= Right_Side . Initial_State , 
= RLBus . Initial_State , 

= TRUE # ) 


Figure 44 - PVS Specification of the Asynchronous Pilot Flying Example - Part 1 

The specification of the asynchronous system is very similar to the synchronous specification 
given in Figure 18 and Figure 19. The main difference is that the next_state function takes each 
of the four clocks as inputs and passes the appropriate clock value to each component. 
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% 

% Next state function 

% 

next_state(s: State, CLK1, CLK2 , CLK3 , CLK4 , TS : bool): State = 

LET 

% 

% Compute the next state of LR Bus and the Right Side 

% 

Cl = Left_Side . output ( Left_Side ( s )) , 

next^LR = LRBus . next_state ( LRBus ( s ) , CLK2, Cl), 

C2 = LRBus . output ( next_LR) , 

next^RS = Right_Side . next_state ( Right_Side ( s ) , CLK3, TS, C2 ) , 

% 

% Compute the next state of the RL Bus and the Left Side 

% 

C3 = Right_Side . output ( Right_Side ( s )) , 

next^RL = RLBus . next_state ( RLBus ( s ) , CLK4, C3), 

C4 = RLBus . output ( next_RL ) , 

next^LS = Lef t_Side . next_state ( Lef t_Side ( s ) , CLK1, TS, C4) 

IN 

(# Left_Side := nextLS, 

LRBus := nextLR, 

Right_Side := nextRS, 

RLBus := nextRL, 

pre_TS := TS #) 

% 

% Outputs 

% 

Lef t Pilot_Flying_Side ( s : State) : bool = pf s ( output ( Lef t_Side ( s )) ) 

Right_Pilot_Flying_Side ( s : State): bool = pfs ( output ( Right_Side ( s )) ) 
END Pilot_Flying_System 


Figure 45 - PVS Specification of the Asynchronous Pilot Flying Example - Part 2 
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3.4.7 Formal Verification of the Asynchronous Pilot Flying Example 

Formal verification of the asynchronous Pilot Flying system proceeds in much the same was as 
for verification of the synchronous example. The informal requirements for the asynchronous 
system are identical to those for the synchronous system: 

R1 . At least one side shall be the pilot flying side. 

R2. At most one side shall be the pilot flying side. 

R3. Pressing the Transfer Switch shall always change the pilot flying side. 

R4. The system shall start with the Primary Side as the pilot flying side. 

R5. The system shall not change the pilot flying side unless the Transfer Switch is pressed. 

The formal specification of these requirements is shown in Figure 46 through Figure 56. 

The definition of a Reachable State is similar to that given for the synchronous example except 
that the next_state function now depends on the clock of each component. Since each component 
only takes a step if its clock is true, this means that there are more reachable states than for the 
synchronous system. This is to be expected since it is the varying execution rates of the 
components that are the source of potential race conditions and deadlocks. 

To simplify the fonnal specification of the requirements, we define a stable_state to be one in 
which the ack of each side is true. This corresponds to the states where one side is in the 
Confirmed sub-state and the other side is in the Listening sub-state (see Figure 36). Of course, it 
also includes states where both sides are in the Confirmed or Listening sub-state, but these will 
be excluded in the fonnal specification of the requirements as unreachable states. 

Since the two sides may now execute on different steps, it is no longer true that if one side sees 
the Transfer Switch pressed, the other side will also see the Transfer Switch pressed on the same 
step. To more precisely specify requirements involving the Transfer Switch, we introduce three 
definitions for when the Transfer Switch is pressed. The predicates pressed _seen_left and 
pressed_seen_right are true when the Transfer Switch is observed to be pressed by the left or 
right side respectively, i.e. when the Transfer Switch has risen from the previous value observed 
by that side. The predicate pressed is true when the Transfer Switch has risen from its previous 
value regardless of the value of each side’s clock. 


73 



Pilot_Flying_System_Requirements : THEORY 
BEGIN 

IMPORTING Pilot Flying_System 

s: VAR Pilot_Flying_System. State 

ml, m2, m3: VAR Message 

ts, clkl, clk2, clk3, clk4: VAR bool 

% 

% Definition of a reachable state 

% 

Reachable_State ( s ) : INDUCTIVE bool = 
s = Initial_State OR 

(EXISTS (r: Pilot_Flying_System. State, cl, c2, c3, c4, t: bool): 
Reachable_State ( r ) AND 

s = next_state ( r , cl, c2, c3, c4, t)) 

% 

% The system is stable when both side ' s acks are true 

% 

stable_state ( s ) : bool = 

( ack ( output ( Left_Side ( s )) ) and ack ( output ( Right_Side ( s ))) ) 

% 

% Definitions for Transfer Switch pressed 

% 

pressed (ts, s) : bool = NOT pre_TS(s) AND ts 

pressed_seen_lef t ( ts , s) : bool = not pre_TS ( Lef t_Side ( s ) ) and ts 
pressed_seen_right ( ts , s): bool = not pre_TS ( Right_Side ( s ) ) and ts; 


Figure 46 - Asynchronous Pilot Flying System Requirements (Part 1) 

Verification of the system properties is based on definition of a VaIid_State predicate just as was 
done for the synchronous example. However, definition of the Valid_State predicate is more 
complex in the asynchronous system and makes use of several auxiliary definitions shown in 
Figure 47. 
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% 

% Predicates used to define Valid State 

% 

Confirmed (ml ) : bool = pfs(ml) AND ack(ml); 

Inhibited(ml ) : bool = NOT pfs(ml) AND NOT ack(ml); 

Listening(ml ) : bool = NOT pfs(ml) AND ack(ml); 

Waiting (ml) : bool = pfs(ml) AND NOT ack(ml); 

% 

% Equality of messages 

% 

== : [Message, Message -> bool] = 

LAMBDA (ml, m2) : pfs(ml) = pfs(m2) AND ack(ml) = ack(m2); 

% 

% Ordering of messages 

% 

» : [Message, Message -> bool] = LAMBDA (ml, m2) : 

Inhibited ( ml ) AND Confirmed (m2 ) OR 
Listening(ml ) AND Inhibited(m2 ) OR 
Waiting(ml) AND Listening(m2 ) OR 
Confirmed (ml ) AND Waiting (m2); 


Figure 47 - Asynchronous Pilot Flying System Requirements (Part 2) 

Since each side generates an output message consisting of a pilot flying indication (pfs ) and an 
acknowledgement ( ack ), it is convenient to name each of the four possible messages to match the 
sub-state of the side from which it is generated. This is done by defining predicates Confirmed, 
Inhibited, Listening and Waiting over the type Message as shown in Figure 47. We also define 
equality over Messages and an ordering of Messages. The intuition behind the ordering relation 
is that a message ml follows a message m2 (i ml » m2) if ml is the next state after m2 in the 
state transition diagram of Figure 36, i.e. Inhibited » Confirmed, Listening » Inhibited and so 
forth. 
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% 


% Valid state constraints over component states 

% 


Side_Bus_Side_Consistency (ml , m2 , 
ml == m2 and m2 == m3 OR 

ml » m2 and m2 == m3 OR 

ml == m2 and m2 » m3 OR 

Waiting(ml) AND Inhibited(m2 ) 
Waiting(ml) AND Listening(m2 ) 
Waiting(ml) AND Waiting (m2) 


m3 ) : bool = 


AND Inhibited ( m3 ) OR 
AND Inhibited(m3 ) OR 
AND Inhibited(m3 ) 


% 

% Valid state constraints on side components 

% 

Side_Consistency (ml , m2) : bool = 

Listening(ml ) AND Conf irmed(m2 ) OR 
Waiting (ml) AND Inhibited(m2 ) OR 
Conf irmed(ml ) AND Listening(m2 ) OR 
Conf irmed(ml ) AND Waiting (m2) OR 
Inhibited(ml ) AND Conf irmed(m2 ) 


% 

% Full definition of a valid state 

% 

Valid^State: [ Pilot_Flying_System. State -> bool] = 

{s | LET 

LS = output ( Left_Side ( s )) , 

LR = LRBus . output ( LRBus ( s )) , 

RP = preMSG ( Right_Side ( s ) ) , 

RS = output ( Right_Side ( s )) , 

RL = RLBus . output ( RLBus ( s )) , 

LP = preMSG ( Lef t_Side ( s ) ) 

IN 

Side_Bus_Side_Consistency ( LS , LR, RP ) AND 
Side_Bus_Side_Consistency ( RS , RL, LP ) AND 
Side_Consistency ( LP , LS ) AND 

Side_Consistency ( RP , RS ) 


% 

% Proof that every reachable state is a valid state 

% 

Reachable_States_Valid : THEOREM 

Reachable_State ( s ) => Valid State ( s ) 


Figure 48 - Asynchronous Pilot Flying System Requirements (Part 3) 

There are two types of consistency defined in Figure 48 that we wish to enforce in the definition 
of Valid_State. Si de_B us _Side Consistency captures the constraint that if a change in sub-state 
occurs in a side, it will transfer across the bus and eventually be stored in the other side as the 
previous value of the first side’s message. To illustrate, consider the case where ml is the output 
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message of the Left_Side, m2 is the output message of the LRBus, and m3 is the pre_MSG of the 
RightJSide (an analogous situation holds for the Right_Side, RLBus, and LeftSide). One 
possibility is that the sub-state of the Left_Side has been transmitted to the Right_Side and ml, 
m2 and m3 are identical (ml == m2 and m2 == m3). Another possibility is that the Left_Side has 
just changed to a following sub-state, but the LR Bus and the Right Side have not yet seen the 
change (ml » m2 and m2 == m3). Another possibility is that the LR Bus has been updated but 
the change has not yet reached the Right_Side (ml == m2 and m2 » m3). 

There are three other possible relationships that are explicitly enumerated in 
Side _Bus _Side -Consistency. Let ml, m2, and m3 be as just described. Consider the situation 
where the Left_Side has just entered the Listening sub-state, but that information has not yet been 
communicated to the LR Bus so that the system is in the state Listening(ml), Inhibited(m2) and 
Inhibited(m3). The first case occurs when the Transfer Switch is pressed and the system enters 
the state Waiting(ml), Inhibited(m2) and Inhibited(m3). The second case occurs when the 
Transfer Switch is pressed while in the state Listening(ml), Listening(m2) and Inhibited(m3) , 
putting the system into the state Waiting(ml) and Listening(m2) and Inhibited(m3). The third 
case evolves directly from the second case when the LRBus is updated with the Left -Side's 
output, putting the system into the Waiting(ml) and Waiting(m2) and Inhibited(m3) state. 
Analogous situations exist for the Right_Side, RL Bus, and the Left_Side. 

The Side -Consistency predicate identifies relationships that must be maintained between the sub- 
state of a side and its copy of the previous message from the other side. For example, if a side is 
in the Confirmed sub-state, then the previous message from the other side must be either 
Listening or Inhibited. 

All of these constraints on the valid system states are collected in the definition of Valid_State in 
Figure 48. The Reachable States Valid theorem states that all reachable states are also valid 
states for the asynchronous Pilot Flying system. The proof of this theorem is similar to the proof 
for the synchronous example shown in Figure 23, but due to the larger number of reachable 
states, more work is needed to keep the proof tractable. For example, simply applying the PVS 
grind command to the inductive branch of the proof as was done in the synchronous case 
generates 544 sub-goals. While each of these can be easily dispatched with a few PVS 
commands, the proof can be almost fully automated with two additional steps. 
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When proving the 544 sub-goals, the PVS theorem prover often requires human assistance to 
case split a sub-goal in order to determine which of the SideHLR axioms should be invoked. It 
is actually easier for the theorem prover to use a constructive definition more like that found in 
the SideLLR theory. However, we prefer to maintain the declarative style using axioms found in 
Side HLR since this is closer to the traditional “shall” statements software engineers expect to 
receive as requirements. To do this while still facilitating theorem proving, we add to the 
Side HLR theory the two lemmas as shown in Figure 49. 


% 

% Lemmas used to simplify system level proofs 

% 

LI : LEMMA 

FORALL (s: State, elk: bool, ts:bool, m: Message) : 
output ( next_state ( s , elk, ts, m) ) = 

IF (NOT elk) THEN 
output ( s ) 

ELSIF ( confirmed ( s ) AND rise_ospf(s, m) ) THEN 
(# pfs := FALSE, ack := FALSE #) 

ELSIF ( inhibited ( s ) AND ack(m)) THEN 
(# pfs := FALSE, ack := TRUE #) 

ELSIF ( listening ( s ) AND rise_ts(s, ts)) THEN 
(# pfs := TRUE, ack := FALSE #) 

ELSIF (waiting(s) AND fall_ack(s, m) ) THEN 
(# pfs := TRUE, ack := TRUE #) 

ELSE 

output ( s ) 

ENDIF 
L2 : LEMMA 

forall (s: State, elk: bool, ts:bool, m: Message) : 
pre_MSG ( next_state ( s , elk, ts, m) ) = 

IF (NOT elk) THEN pre_MSG(s) ELSE m ENDIF 


Figure 49 - Lemmas Added to Side_HLR to Support Theorem Proving 

These lemmas define the effect of applying the output and pre MSG extractors to the next_state 
constructor in a constructive style that defines the result for all possible conditions. These 
lemmas can easily be proven using the axioms of Side HLR and the PVS theorem prover can be 
instructed to invoke these lemmas as automatic rewrite rules using the PVS use command. This 
eliminates the need for manual intervention to case split a sub-goal. 

The second step for proof automation is to define a custom PVS strategy. PVS strategies can be 
thought of as user-defined proof commands constructed from the basic proof commands of PVS. 
The strategy needed here is shown in Figure 50. 
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(defstep grind-use-grind (&rest lemmas) 

(let ( (uselems (cons 'use* lemmas))) 

( then 

(grind) uselems (grind) 

)) 

"Applies grind, then uses lemmas followed by grind on on each subgoal." 
"Applying grind - use - grind." 


Figure 50 - Grind-use-grind PVS Proof Strategy 

This strategy defines a PVS proof command called grind-use-grind that accepts a sequence of 
lemma names as an argument. Its effect is to apply the PVS grind command to the current sub- 
goal, possibly generating one or more new sub-goals. It then invokes the named lemmas on each 
new sub-goal with the PVS use command, and finally applies the grind command to that sub- 
goal. An illustration of its use is shown in the last step of the proof for the asynchronous 
Reachable _States_VaIid theorem shown in Figure 51. 


; ; ; Proof Reachable_States_Valid-l for formula 
Pilot_Flying_System_Requirements . Reachable_States_Valid 
; ; ; developed with shostak decision procedures 

| M II 

(rule-induct "Reachable_State " ) 

( skosimp ) 

(case "s!2 = Initial_State " ) 

( ( " 1 " 

(auto-rewrite-theories "Message" "Left_Side" "LRBus" "Right_Side" 
"RLBus" ) 

(grind) ) 

(" 2 " 

( assert ) 

(hide 1) 

(grind-use-grind "LRBus . HLR2 " "RLBus . HLR2 " "Left_Side .LI " 

"Lef t_Side . L2 " "Right_Side .LI " "Right_Side .L2 " ) ) ) ) 


Figure 51 - PVS Proof of Asynchronous Reachable States Valid Theorem 

Successful completion of the proof of Figure 51 establishes that every reachable state of the 
asynchronous Pilot _Flying_System is also a valid state. The Reachable _States_Valid theorem 
can then be used to prove requirements R1 and R2 shown in Figure 52, both of which can be 
discharged with a PVS (use 'Reachable States _Valid) command followed by a grind command. 
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% 

% R1 . At least one side shall always be the pilot flying side. 

% 

R1 : THEOREM 

Reachable_State ( s ) => 

Lef t_Pilot_Flying_Side ( s ) OR Right Pilot_Flying_Side ( s ) 

% 

% R2 . Both sides shall agree on the pilot flying side 
% except while the system is switching sides. 

% 

R2 : THEOREM 

Reachable_State ( s ) AND stable_state ( s ) => 

( Lef t_Pilot Flying_Side ( s ) = NOT Right Pilot_Flying_Side ( s ) ) 


Figure 52 - Asynchronous Pilot Flying System Requirements (Part 4) 

However, the proof of requirement R3 (pressing the Transfer Switch shall always change the 
pilot flying side) reveals a problem. To formalize R3, we break it into two smaller requirements 
R3a and R3b as shown in Figure 53. 


% 

% R3 . Pressing the transfer switch shall always change the pilot 
% flying side except when the system is switching sides. 

% 

R3a : THEOREM 

Reachable_State ( s ) AND stable_state ( s ) => 

(NOT Lef t_Pilot_Flying_Side ( s ) AND pressed (ts, s) => 

Lef t_Pilot_Flying_Side ( next_state ( s , TRUE , clk2 , clk3 , clk4 , ts ) ) ) 

R3b : THEOREM 

Reachable_State ( s ) AND stable_state ( s ) => 

(NOT Right Pilot_Flying_Side ( s ) AND pressed (ts, s) => 

Right Pilot_Flying_Side ( next_state ( s , clkl , clk2 , TRUE , clk4 , ts ) ) ) 


Figure 53 - Incorrect Statement of Asynchronous Requirement R3 

These requirements state that if the Transfer Switch is pressed while the system is in a stable 
state (i.e. is not switching sides) the side that is not the pilot flying side shall become the pilot 
flying side providing its clock is true. However, trying to prove either theorem generates four 
sub-goals that cannot be proven. These correspond to cases in which the Transfer Switch was 
true the last time the side’s clock was true. In other words, even if the Transfer Switch is pressed 
on this step and the side’s clock is true, the side does not see a rising edge of the Transfer Switch 
because the last time its clock was true the Transfer Switch was also true. 


80 





There is no easy fix for this problem. Instead, the system must be designed to ensure that the 
pilot not flying side sees the Transfer Switch being pressed. In an actual system, it would be 
possible to place additional requirements on the length of time the Transfer Switch must remain 
high and the time it must remain low to ensure that the pilot not flying side would see a rising 
edge of the Transfer Switch, but since we are making no assumptions about the system clock that 
will not work for our system. To make this explicit, we replace the pressed predicate in R3a and 
R3b with pressed _seen_Ieft and pressed _seen_right as shown in Figure 54. This makes it clear 
the requirements are satisfied only if the pilot not flying side actually observes the Transfer 
Switch being pressed. Both of these theorems can be proven with a PVS (use 
"Reachable States Valid”) command followed by a grind-use-grind command invoking the 
appropriate lemmas. 


% 

% R3 . Pressing the transfer switch shall always change the pilot 
% flying side except when the system is switching sides. 

% 

R3a : THEOREM 

Reachable_State ( s ) AND stable_state ( s ) => 

(NOT Lef t_Pilot_Flying_Side ( s ) AND pressed_seen_lef t ( ts , s) => 

Lef t_Pilot_Flying_Side ( next_state ( s , TRUE , clk2 , clk3 , clk4 , ts ) ) ) 

R3b : THEOREM 

Reachable_State ( s ) AND stable_state ( s ) => 

(NOT Right Pilot_Flying_Side ( s ) AND pressed_seen_right ( ts , s) => 

Right Pilot_Flying_Side ( next_state ( s , clkl , clk2 , TRUE , clk4 , ts ) ) ) 

% 

% R4 . The system shall start with the left side as the pilot 
% flying side. 

% 

R4 : THEOREM 

Lef t Pilot_Flying_Side ( Initial_State ) 


Figure 54 - Asynchronous Pilot Flying System Requirements (Part 5) 

Requirement R4 (the system shall start with the left side as the pilot flying side) also shown in 
Figure 54 is easily proven by installing the axioms of Side HLR and Bus HLR as automatic 
rewrite rules followed by a grind command. However, requirement R5 (the system shall not 
change the pilot flying side unless the Transfer Switch is pressed) turns out to not be true as 
formulated in Figure 55 
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% 

% R5 . The system shall not change the pilot flying side while it 
% is in a stable state unless the transfer switch is pressed. 

% 

R5a : THEOREM 

Valid State ( s ) AND stable_state ( s ) AND NOT pressed (ts, s) => 

Lef t_Pilot_Flying_Side ( next_state ( s , clkl , clk2 , clk3 , clk4 , ts ) ) = 
Lef t_Pilot_Flying_Side ( s ) 

R5b : THEOREM 

Valid State ( s ) AND stable_state ( s ) AND NOT pressed (ts, s) => 

Right_Pilot Flying_Side ( next_state ( s , clkl , clk2 , clk3 , clk4 , ts ) ) = 
Right_Pilot_Flying_Side ( s ) 


Figure 55 - Incorrect Statement of Asynchronous Requirement R5 

The counter example for this occurs when the clock for the Not Pilot Flying side becomes false 
while the Transfer Switch is false. At a later time, the Transfer Switch becomes true, but the 
Not_Pilot_Flying side does not observe this rising edge because its clock is still false. The 
Transfer Switch remains true for several steps and during this period, the Not_Pilot_Flying side’s 
clock becomes true. At this point, the Not_Pilot_Flying side observes a rising edge of the 
Transfer Switch and becomes the Pilot _Flying_Side. However, the predicate pressed is not true 
on that step since the Transfer Switch has been true for several steps. 

Requirement R5 is false due to a subtle interaction between the component clocks and their 
stored value of the Transfer Switch. The intent of this requirement was that the system should 
not spontaneously change state while in a stable state unless there is some external stimulation. 
Interestingly enough, it is possible to prove R5 if it is restated as shown in Figure 56. 
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% 

% R5 . The system shall not change the pilot flying side while it 
% is in a stable state unless the transfer switch is high. 

% 

R5a : THEOREM 

Valid_State ( s ) AND stable_state ( s ) AND NOT ts => 

Lef t_Pilot_Flying_Side ( next_state ( s , clkl , clk2 , clk3 , clk4 , ts ) ) = 
Lef t_Pilot_Flying_Side ( s ) 

R5b : THEOREM 

Valid_State ( s ) AND stable_state ( s ) AND NOT ts => 

Right Pilot_Flying_Side ( next_state ( s , clkl , clk2 , clk3 , clk4 , ts ) ) = 
Right_Pilot_Flying_Side ( s ) 

END Pilot_Flying_System_Requirements 


Figure 56 - Asynchronous Pilot Flying System Requirements (Part 6) 

Here, we have replaced the NOT pressed(ts, s) with NOT ts, so that the requirement states that 
the system shall not change the pilot flying side while it is in a stable state unless the Transfer 
Switch is high. While technically a slightly weaker requirement, this formulation still satisfies 
the original intent of the requirement and is easily proven to be true. 
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3.5 The Synchronous Pilot Flying Example in HOL 

Higher Order Logic (HOL) is a formal system originally adopted and implemented by Mike 
Gordon [7], [8]. Subsequently, other implementations of HOL have been developed [24], [25], 
[13], [27], [26], [17]. In general, these systems agree on the formal system implemented [24], but 
their interfaces and proof infrastructure can be quite different. In our example we will work with 
HOL4 [25], [12]. 

In HOL4 notation, is the ‘not’ operator, ‘A’ is conjunction, ‘V’ is disjunction, ‘T’ is True, and 
‘F’ is False. The T symbol is ‘for all’, and the ‘?’ symbol is ‘there exists’. Finally, ‘<|’ and ‘ |>’ 
are used to indicate a record structure. 

3.5.1 Specification in HOL4 using a Next-State Approach 

This section describes a HOL4 specification of the synchronous pilot flying example using a 
“this state, next state” approach similar to what was done in PVS. We start by defining the RISE 
function in terms of a Boolean signal s. We then define data types for PFS (cf. Pilot _Flying_Side 
type in Figure 15) and Side_State (cf. State type in Figure 15). We also define System _State (cf. 
State type in Figure 18). These HOL4 definitions are shown in Figure 57. 
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numLib . pref er_num ( ) ; 

(* 

(* Rise definition 


val RISE^def = 

Define 

'RISE(pre_s : bool, 
s : bool) 

~pre_s /\ s'; 


*) 

*) 

*) 


(* 

(* Data type definitions 
(* 

Hol_datatype 

'PFS = Pilot Flying 

| Not_Pilot__Flying ' ; 

Hol_datatype 
'Side_State = 

<| st: PFS; 

pre_ts: bool; 
pre_ospf: bool 
I >' ; 

Hol_datatype 

' System_State = 

<| stateLS: Side_State; 
stateLR: bool; 
stateRS: Side_State; 
stateRL: bool; 
pre_ts: bool 
I > ' ; 


*) 

*) 

*) 


Figure 57 - Rise and Data Type Definitions 

Next we define the initial states for the sides (both the primary side and the non-primary side), 
the buses, and the system. These are shown in Figure 58 and correspond with the initial state 
definitions in PVS. 


85 



val Initial_Side_State_Primary_def 
Define 

' Initial_Side_State_Primary = 


val Initial_Side_State_Not_Primary_def 
Define 

' Initial_Side_State_Not_Primary = <| 


val Initial_Bus_State_Primary_def = 
Define 

' Initial_Bus_State_Primary = T'; 

val Initial_Bus_State_Not_Primary_def 
Define 

' Initial_Bus_State_Not_Primary = F' 

val Initial_System State_def = 

Define 

' Initial_System_State = < | stateLS 

stateLR 

stateRS 

stateRL 

pre_ts 


<| st:= Pilot_Flying; 
pre_ts:= T; 
pre_ospf:= F |>'; 


st:= Not_Pilot_Flying; 
pre_ts:= T; 
pre_ospf:= T |>'; 


= Initial Side_State_Primary; 

= Initial Bus_State_Primary; 

= Initial Side_State_Not_Primary; 
= Initial Bus_State Not_Primary; 

= T | > ' ; 


Figure 58 - Initial State Definitions 

To complete the specification, we have left to define the next state functions for Side, Bus, and 
System. These functions are called Sidejis, Bus ns, and Systemjis in the code shown in Figure 
59. Note that the Bus ns function simply returns the input value. The delay is implemented at the 
top level in the Systemjis function. 
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val Side ns def = 


Define 


'Side ns (state : Side State, 

ts : bool. 


ospf : bool) = 

= 

let 


nextst = 


if (state. st = Pilot Flying) /\ RISE ( state . pre ospf, ospf) 

then Not Pilot Flying 

else if (state. st = Not Pilot Flying) /\ RISE ( state . pre ts, ts) 

then Pilot Flying 


else state. st 


in 


state with <| st:= nextst; pre ts:= ts; pre ospf:= ospf |>'; 

val Bus ns def = 


Define 


'Bus ns (input : bool) = 

input ' ; 

val System ns def = 


Define 


'System ns (state : System State, 

ts : bool) 

= 

let 


nextLR = Bus ns ( state . stateLS . st = Pilot Flying) and 

nextRL = Bus ns ( state . stateRS . st = Pilot Flying) 

in 


state with < | stateLS 

= Side ns ( state . stateLS , ts, nextRL); 

stateLR 

= nextLR; 

stateRS 

= Side ns ( state . stateRS , ts, nextLR); 

stateRL 

= nextRL; 

pre ts 

= ts | > ' ; 




Figure 59 - Next State Definitions 

3.5.2 Formal Verification of the Next-State Approach in HOL4 

In this section we discuss fonnal verification in HOL4 of the specification described in the 
previous section. We prove one property (“At Least One Side Flying”) as an example. 

Proving properties of the system proceeds in a manner very similar to that used in PVS. We will 
walk through the proof of the first property, Rl: “At least one side shall be the pilot flying side.” 
We first define Reachable State. We then define Valid_State, which contains all system states 
satisfying the following four predicates: Pre TS Consistency, Pre OSPF Consistency, 
At_Least_One_Side_Flying, and Buses _Differ_When_Both_Sides_Flying. These definitions are 
shown in Figure 60. 
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(* 

(* Reachable_State 
(* 


val reachable = Hol_reln 
'Reachable Initial_System_State 
/\ 

(!sl s2 ts. Reachable si /\ (System_ns (si, ts) = s2) ==> Reachable s2) '; 
val (Reachable_rules, Reachable_induction, Reachable_cases) = reachable; 

*) 
*) 
*) 

val Pre_TS_Consistency_def = 

Define 

' Pre_TS_Consistency s = 

( s . stateLS . pre_ts = s.pre_ts) /\ ( s . stateRS . pre_ts = s.pre_ts)'; 

val Pre_OSPF_Consistency_def = 

Define 

' Pre_OSPF_Consistency s = 

( s . stateLS . pre_ospf = s.stateRL) /\ ( s . stateRS . pre_ospf = s.stateLR)'; 

val At_Least_One_Side_Flying_def = 

Define 

' At_Least_One_Side_Flying s = 

( s . stateLS . st = Pilot_Flying) \/ ( s . stateRS . st = Pilot_Flying) ' ; 

val Buses_Dif f er_When_Both_Sides_Flying_def = 

Define 

' Buses_Dif f er_When_Both_Sides_Flying s = 

( s . stateLS . st = Pilot_Flying) /\ ( s . stateRS . st = Pilot_Flying) 

==> ~ (s.stateLR = s.stateRL)'; 


(* 

(* Definitions required by Valid_State 
(* 7 


(* 

(* Valid_State 
(* 


val Valid_State_def 
Define 

'Valid State s = 


Pre_TS_Consistency s /\ 
Pre_OSPF_Consistency s /\ 
At_Least_One_Side_Flying s /\ 
Buses Differ When Both Sides 


Flying 


s ' ; 


*) 

*) 

*) 


Figure 60 - Valid State Definition 

We wish to show the first property, Rl: “At least one side shall be the pilot flying side.” We do 
this in two steps. We show that all reachable states are valid, and then we show that all valid 
states satisfy Rl. First, we define a custom simplification set (shown in Figure 61), which we 
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will use in nearly all of our proofs. This simplification set expands the definitions in our 
specification as needed and includes LETTHM to simplify complicated LET expressions. 


val sys_ss = srw_ss() ++ rewrites 
[ Pre_TS_Consistency_def , 
Pre_OSPF_Consistency_def , 
At_Least_One_Side_Flying_def , 

Buses_Dif f er_When_Both Sides_Flying_def , 
Valid_State_def , 

Side_ns_def , 

Bus_ns_def , 

System_ns_def , 

RISE^def , 

Initial_System_State_def , 
Initial_Side_State Primary_def, 
Initial_Side_State Not_Primary_def , 
Initial_Bus_State_Primary_def , 
Initial_Bus_State_Not_Primary_def , 

LET THM] ; 


Figure 61 - Custom Simplification Set sys_ss 

Using the sys_ss simplification set just defined, we can show that the initial state is valid and that 
the next state of a valid state is valid. These two theorems are then used to show that all 
reachable states are valid (see Figure 62). 


val Valid State__Base = 'Valid_State Initial_System_State ' ' ; 


val Valid_State_Base_Thm = prove 
(Valid_State_Base , 

RW_TAC sys_ss [] THEN METIS_TAC [ ] ) ; 
val Valid__State_Inductive = 

''!s ts. Valid_State s ==> Valid_State (System_ns (s, ts) ) ' ' ; 

val Valid_State_Inductive_Thm = prove 
(Valid_State_Inductive , 

RW_TAC sys_ss [] THEN METIS_TAC [ ] ) ; 

val Reachable_States_Are_Valid = prove 
( ' ' ! s . Reachable s ==> Valid_State s''. 

Induction 'Reachable s' 

THEN METIS_TAC [ Valid_State_Base_Thm, 

Valid_State_Inductive_Thm] ) ; 


Figure 62 - HOL4 Proof that all Reachable States are Valid 


89 





Next we show that all valid states satisfy Rl: “At least one side shall be the pilot flying side.” 
The proof is done using rewriting with the custom simplification set sys_ss as shown in 



Figure 63 - HOL4 Proof that All Valid States Satisfy Rl 

We now put the two pieces together to prove that all reachable states satisfy Rl. 


val Rl_Thm_Reachable = store__thm 

("Rl_Thm"7 

''!s. Reachable s ==> 

( s . stateLS . st = Pilot_Flying) \/ ( s . stateRS . st = Pilot_Flying) ' ' , 

METIS^TAC [Rl Thm, Reachable_States_Are_Valid] ) ; 


Figure 64 - HOL4 Proof that All Valid States Satisfy Rl 

3.5.3 Specification in HOL4 using a Streams Approach 

Modeling components that operate over infinite streams of data can be approached in a variety of 
ways. An approach that is well-suited to higher order logic represents a stream of elements, 
where each element has type x, by a function of type num— > x. A device, or component, having a 
number of ports is modeled as a predicate on the possible values of the ports. Since a port is a 
stream, the behavior of the device is represented by a predicate that takes a bundle of streams and 
returns true or false. 

For example, a bus that acts as a unit delay can be represented as 


Bus (init, input, output) = 
(output 0 = init) /\ 
(output (n+1) = input n) 


Figure 65 - Bus Specification with Streams Approach 

where input and output have type num— >a, and init, the initial value of the stream, has type a. 
The type variable a shows that the definition is polymorphic, and thus can be instantiated to yield 
a bus over streams of any type. 
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The parallel composition of devices is achieved by conjunction of the corresponding predicates. 
Combining devices by connecting them together is modeled by relational composition: the 
resulting device is a predicate on the external ports, and internal connections are hidden by 
existential quantification. Thus, we may obtain a bus that delays data by two clock ticks by 
composing two buses: 

Two_Delay_Bus (initl, init2, input, output) = 

?c. Bus (initl, input, c) /\ 

Bus (init2, c, output) 

Figure 66 - Two-Delay Bus Specification with Streams Approach 

Suppose we want to say that there has been a "rise" at time t on a Boolean stream, written "RISE 
stream t". At time zero there can be no rise. At any other time, a rise occurs at time t if the line is 
low at time t-1 and high at time t. This can be directly modeled as follows: 

(RISE stream 0 = F) /\ 

(RISE stream (t+1) = -(stream t) /\ stream (t+1) 

Figure 67 - ‘Rise’ Definition with Streams Approach 

The RISE predicate has been defined by explicit case analysis on whether a number is zero or a 
successor. An equivalent definition is the following: 

RISE stream t = if t = 0 then F else -(stream (t-1)) /\ stream t 

Figure 68 - Alternate ‘Rise’ Definition with Streams Approach 

This modeling style has been used successfully on a wide variety of system verifications [20]. It 
is well suited to systems where all components share the same clock, but it can also be extended 
to deal with asynchronous systems with handshakes, for example. It can express circuits with 
feedback loops without having to solve tricky recursive equations. 

3.5.3. 1 Properties 

Expressing properties of systems modeled in this style involves asserting that the behaviors of a 
device, or implementation, are contained within the behaviors allowed by a specification. Using 
the fact that subset is defined by implication, we obtain the general recipe: 
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implementation ==> specification 

This can also be read as "anything that models the implementation is also a model of the 
specification". Note that there is a residual question to be dealt with, namely one would want to 
show that there is indeed a model of the implementation. However, when working with 
implementations imported into logic from an existing design, this step is often skipped over. 

3. 5. 3. 2 System Model 

We will proceed in a top-down fashion. The flight guidance system can be directly modeled as 
follows: 


System (L, R, Transfer Switch) = 




?wl w2 . 




Side (T, Transfer Switch, w2,L) 

/\ 

(* 

Left Side *) 

Side (F, Transfer Switch, wl,R) 

/\ 

(* 

Right Side *) 

Bus (L, wl ) /\ 


(* 

LR Bus *) 

Bus (R, w2 ) 


(* 

RL Bus *) 


Figure 69 - System Specification with Streams Approach 

The external ports of the system are L, R, and Transfer Switch. There are also two internal buses 
wl, w2 that connect the two sides. The left side is initialized with T and the right side with F, 
setting the initial pilot flying side. Both sides take the transfer switch as input and connect to the 
buses and the external ports L and R. 

Each Side component implements some decision-making logic. This is defined as follows: 


Side (Initial Pilot_Flying_Side : bool, 

Transf er_Switch : num->bool, 

Other_Side Pilot_Flying : num->bool, 

Pilot_Flying_Side : num->bool) 

( Pilot_Flying_Side 0 = Initial_Pilot_Flying_Side ) /\ 
(!t. Pilot_Flying_Side (SUC t) = 

if (Pilot_Flying_Side t = T) /\ 

RISE Other_Side_Pilot_Flying (SUC t) 
then F 

else if (Pilot_Flying_Side t = F) /\ 

RISE Transf er_Switch (SUC t) 
then T 

else Pilot_Flying_Side t) 


Figure 70 - Side Specification with Streams Approach 
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This tiny state machine is defined by case analysis on whether the system is at its initial step 
(time 0) or otherwise. 

We have specified the buses as pure unit delays, omitting to specify the output at time zero: 

Bus ( instream : num->bool , outstream : num->bool ) 

!t. outstream (SUC t) = instream t 

Figure 71 - Final Bus Specification for Streams Approach 

In an earlier fonnalization of the system, initial values were specified for the buses, but the 
proofs revealed that the proof succeeded no matter what the initial values were set to. By 
omitting initial values, the statements and proofs about the system become more general, since 
any possible initial values will be acceptable for the purposes of proof. 

3.5.4 Formal Verification of the Streams Approach in HOL4 

We proved two facts about the system in HOL4. First, we proved that the L port is high at time 
zero. The statement of this is 


System (L, R, Transf er_Switch) ==> L(0) 

Figure 72 - Statement of R4 Property 

and the proof is quite straightforward, as we discuss below. Next, we proved that at least one side 
is the pilot flying side: 

System (L, R, Transf er_Switch) ==> !t. L(t) \/ R(t) 

Figure 73 - Statement of R1 Property 

This proof is more challenging but still relatively small. 

3. 5.4.1 Left at Time Zero 

This proof is straightforward. We merely simplify with the system definitions and then reduce. 
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val Lef t_at_Time_Zero = prove 
('' System (L, R, Transf er_Switch) ==> L(0)'', 
RW_TAC std_ss [System_def , Side_def , Bus_def ] ) ; 


Figure 74 - Proof of R4 Property for Streams Approach 
3. 5.4.2 At Least One Side Flying 

This property is more challenging. It requires induction and the system state at time t can depend 
on the state at times t - 1 and t- 2, which means that complete induction is needed. The proof then 
proceeds by case analysis on whether the system is at step 0, 1, or some arbitrary number greater 
than one. The base cases are simple to prove by simplification with the definitions of the system 
components. The inductive hypothesis yields 4 possible combinations for values of the two 
PilotFlyingSide ports at the two previous steps in the computation. Some basic reasoning 
finishes the proof. 

The full proof of this property, once packaged up, is shown in Figure 75. 


val At_Least_One_Side_Flying = 

Count. apply prove 

('' System (L, R, Transf er_Switch) ==> !t. L(t) \/ R(t)'', 

DISCH_TAC 

THEN completeInduct_on 't' 

THEN ' (t = 0) \/ (t = SUC 0) \/ ?k . t = SUC (SUC k) ' 
by METIS_TAC [ arithmeticTheory . num_CASES ] 

THEN FULL_SIMP_TAC kstd_ss [ System_def , Bus_def , Side_def , RISE_def ] 
THEN ' (L k \/ R k) /\ (L (SUC k) \/ R (SUC k) ) ' 

by METIS_TAC [prim^recTheory . LESS_SUC_SUC] 

THEN METIS TAC [ ] ) ; 


Figure 75 - Proof of R1 Property for Streams Approach 

Elapsed time was about a fifth of a second. In the course of the proof, no axioms were declared, 
no definitions were made, and no theories were brought in from disk. Approximately 41,000 
primitive inference steps were required to achieve the proof. 
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4 Case Study: Model Checking 

This chapter illustrates the use of model checking to verify the correctness of the mode logic of a 
single side of the FGS. The FGS mode logic, while quite complex, consists only of Boolean 
inputs and outputs. This makes it ideally suited for formal verification with a wide range of 
model checkers, including implicit state BDD-based model checkers such as NuSMV as well as 
Satisfiability Modulo Theories (SMT)-based model checkers such as Kind. While models 
consisting only of Boolean logic are well-suited for model checking, most model checkers can 
also handle models with enumerated types and small integers. SMT-based model checkers such 
as Kind can also handle models with real numbers if they do not involve nonlinear arithmetic. 

The rest of this chapter is organized as follows. Section 4.1 provides an overview of the FGS 
mode logic. Section 4.2 describes the software verification plan for the mode logic, identifying 
the life-cycle data items to be produced, the DO-178C objectives to be satisfied, and tool 
qualification issues. Section 4.3 provides a detailed specification of the mode logic as a 
MATLAB Simulink/Stateflow model. Section 4.4 discusses the formal verification of the mode 
logic using the Kind model checker and Simuli nk Design Verifier™. 

4.1 Mode Logic Overview 

Modes are defined by Leveson as mutually exclusive sets of system behaviors [18]. Specifically 
as it relates to the FGS, Advisory Circular AC/ACJ 25.1329 defines a mode as a system 
configuration that corresponds to a single (or set of) FGS behavior(s) [5], In the FGS, the modes 
are actually abstractions of their associated flight control law and reflect the current state of the 
flight control law. There are three different types of modes in the FGS mode logic. 

The simplest modes (non-arming modes) have only two actual states, CLEARED and 
SELECTED, as shown in Figure 76. A mode is said to be selected if it has been manually 
requested by the flight crew or if it has been automatically requested by a subsystem such as the 
FMS, otherwise it is said to be cleared. Non-arming modes become active immediately upon 
selection with its associated flight control law providing guidance commands to the FD and, if 
engaged, the AP. When cleared, the mode’s associated flight control law is non-operational, i.e., 
it does not generate any outputs. 
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Figure 76 - A Non-Arming Mode 

Some modes must first be armed to become active when a capture condition is met, such as the 
acquisition of a navigation source or proximity to a target reference such as a desired altitude. 
Such modes have three states as shown in Figure 77. The two states ARMED and ACTIVE are 
sub-states of the SELECTED state, i.e., when the mode is armed or active, it is also selected. 
While in the ARMED state, the mode’s flight control law is not generating guidance commands 
for the FD or AP, but it may be accepting inputs, accumulating state infonnation, and helping to 
detennine if the capture condition is met. Once the capture condition is met, the mode transitions 
to the ACTIVE state and its flight control law begins generating guidance for the FD and AP. 
Note that in most anning modes the only way to exit the ACTIVE state is to deselect the mode, 
i.e., it is not usually possible to revert directly from the ACTIVE state to the ARMED state. 



Figure 77 - An Arming Mode 

Some modes also distinguish between capturing and tracking the target. Such a mode is shown in 
Figure 78. Once in the ACTIVE state, such a mode’s flight control law first captures the target by 
maneuvering the aircraft to align it with the navigation source or reference. Once correctly 
aligned, the mode transitions to the tracking state in which it holds the aircraft on the target. Both 
the CAPTURE and TRACK states are sub-states of the ACTIVE state and the mode’s flight 
control law is active in both states, i.e., generating guidance commands for the FD and AP. Note 
that the only way to exit the ACTIVE state is to deselect the mode, i.e., it is not usually possible 
to revert directly from the TRACK state to the CAPTURE state or from the ACTIVE state to the 
ARMED state. 
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Figure 78 - A Capture/Track Mode 

The FGS modes are organized into the lateral modes, which control the behavior of the aircraft 
about the longitudinal, or roll, axis of the aircraft and the vertical modes, which control the 
behavior of the aircraft about the lateral, or pitch, axis of the aircraft. The lateral modes in this 
example include Roll Hold, Lateral Navigation, Lateral Approach and Lateral Go Around. The 
vertical modes include Pitch Hold, Vertical Speed, Flight Level Change, Altitude Hold, Altitude 
Select, Vertical Approach and Vertical Go Around. 

The mode logic of the FGS consists of the specification of these individual modes and the rules 
for transitioning between them. To provide proper guidance of the aircraft, these modes are 
tightly synchronized so that only a small portion of their total state space is actually reachable. 
For example, since at least one lateral and one vertical mode must be active and providing 
guidance whenever the FD is displayed or the AP is engaged, one mode is designated as the 
basic mode for each axis. The basic mode is automatically activated if no other mode is active 
for that axis. In this example, the basic modes are Roll Hold and Pitch Hold. In similar fashion, 
only one lateral mode and one vertical mode can provide guidance to the FD and the AP at the 
same time, so the mode logic must ensure that at most one lateral and one vertical mode are ever 
active at the same time. 

Other constraints enforce relationships between the modes that are dictated by the characteristics 
of the aircraft and the airspace. For example, Vertical Approach mode is not allowed to become 
active until Lateral Approach mode has become active to ensure that the aircraft is horizontally 
centered on the localizer before tracking the glideslope. As another example, if the pilot cancels 
a landing and performs a go around, Lateral and Vertical Go Around modes must both be active. 
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Still other relationships must be maintained between the mode logic and the surrounding 
systems. For example, the AP should never be engaged when Lateral and Vertical Go Around 
modes are active since the pilot should be manually flying the aircraft during a go around. 

While verifying the behavior of a single mode is straightforward, ensuring that all the 
relationships between the modes and the aircraft are always maintained can be very complex. 
Moreover, since many of these relationships are of the fonn “the mode logic shall always ensure 
relationship x” they cannot be fully verified with testing since testing can only verify a small 
sample of the total inputs and states. In contrast, model checking is an ideal way to verify these 
relationships. All of the relationships described above and many others are formally stated and 
verified in Section 4.4. 

4.2 Software Verification Plan 

In this case study, we will use model checking to perform verification activities associated with 
the outputs of the software design process, focusing on the objectives of Table A-4 in DO-178C 
and Table FM.A-4 in DO-333. The purpose of these verification activities is to detect any errors 
that may have been introduced during the software design process (DO-178C Section 5.2). 
Specifically, this case study will verify the low-level software requirements for the mode logic of 
a side of the FGS and show that the software architecture and the low-level software 
requirements comply with the high-level software requirements. 

4.2.1 Formal Specification and Verification Tools 

The low-level software requirements and software architecture will be specified as MATLAB 
Simulink and State flow models. These models will be translated into the Lustre formal 
specification language using a proprietary Rockwell Collins tool. Lustre is the input language of 
the JKind SMT-based model checker [14]. JKind is a Java implementation of the Kind model 
checker developed by the University of Iowa [9], 

Kind and JKind make use of SMT (Satisfiability Modulo Theories) solvers and the k-induction 
inference principle. SMT solvers are tools for detennining the satisfiability of logical 
expressions containing a finite number of terms. A bounded model checking problem (one that 
considers only a finite number of steps) can be mapped to a satisfiability problem. The k- 
induction principle is then used to extend the analysis to traces of infinite length. 
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The high-level software requirements will be specified as Lustre predicates and merged with the 
Lustre specification of the low-level requirements. The low-level software requirements and 
software architecture will be shown to comply with the high-level requirements using JKind. 

To provide a commercially available example, the MATLAB Design Verifier model checker will 
also be used to show that the low-level software requirements and the software architecture 
comply with a subset of the high-level requirements. These high-level requirements will be 
specified using both the MATLAB Simulink graphical and textual notations. 

4.2.2 Life Cycle Data Items 

Life cycle data items for this example are specified using a variety of notations and tools. 

High-Level Software Requirements The high-level software requirements are specified in two 
different ways. For verification with the JKind SMT-based model checker, they are 
specified as predicates in the Lustre formal specification language in the file 
Mode_Logic. lustre-props. For verification with MATLAB Simulink Design Verifier, 
they are specified using both the Simulink graphical and textual notation in the file 
Mode_Logic_Props.mdl. Mode_Logic_Props.mdl also refers to other modeling files, 
including Mode _Logic_Props Jib. mdl which contains Simulink blocks frequently used 
by Mode J,ogic Props. mdl, and mode logic Jnputs. mat, mode Jogic_outputs. mat and 
no Jiigher event. mat which contain Simulink bus definitions for the system inputs, 
outputs and prioritized events. 

Low-Level Software Requirements The low-level software requirements are specified as 
MATLAB Simulink/Stateflow models ModeJ.ogic.mdl and Mode Logic lib. mdl. 

Software Architecture The software architecture is specified as MATLAB Simulink/Stateflow 
models in the files Mode J^ogic. mdl and Mode J^ogic Jib. mdl. 

4.2.3 Objectives to Be Satisfied 

The DO-178C and DO-333 objectives to be satisfied through model checking are summarized in 
Table 2. A more detailed discussion of how each objective is satisfied is provided in this section. 

Objective A-4.1 - Low-level requirements comply with high-level requirements. This objective is 
demonstrated by proving with the JKind model checker or Design Verifier that the high-level 
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software requirements are implemented by the low-level software requirements and the software 
architecture. 

Objective A-4.2 - Low-level requirements are accurate and consistent. This objective is met by 
modeling the low-level requirements and the software architecture in the executable model 
language Simulink/Stateflow and by translating into the formal specification language Lustre. 

Objective A-4.4 - Low-level requirements are verifiable. This objective is met by modeling the low- 
level requirements and the software architecture in the executable model language 
Simulink/Stateflow and by translating that model into the formal specification language Lustre. 

Objective A-4.5 - Low-level requirements conform to standards. This objective is partially met by 
modeling the low-level requirements and the software architecture in the Simulink/Stateflow 
design language. Commonly used blocks are provided in a library of blocks approved for use on 
the project. Models can be automatically checked with the MATLAB Model Advisor for 
conformance with some project defined standards. Conformance to any remaining standards can 
be shown by manual review of the graphical models. 

Objective A-4.6 - Low-level requirements are traceable to high-level requirements. This objective is 
partially met by proving with the JKind model checker or Design Verifier that the high-level 
software requirements are implemented by the low-level software requirements and the software 
architecture, demonstrating that all high-level requirements have been developed into low-level 
requirements. Demonstrating that all low-level requirements can be traced to high-level 
requirements is accomplished through manual review. 

Objective A-4.7 - Algorithms are accurate. This objective is met by modeling the low-level 
requirements in Simulink/Stateflow and proving that the high-level software requirements are 
implemented by the low-level software requirements and the software architecture. 
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Table 2 - Summary of Objectives Satisfied by Model Checking 


Objective 

Description 

A 

B 

C 

D 

Notes 

A. 4.1 

Low-level requirements comply 
with high-level requirements. 

■ 

■ 

■ 


Established by proof that the high-level 
requirements are implemented by the low-level 
requirements and the software architecture. 

A.4.2 

Low-level requirements are 
accurate and consistent. 

■ 

■ 

■ 


Established by modeling using an executable 
language and translation to a formal specification 
language. 

A.4.3 

Low-level requirements are 
compatible with target computer. 





Not addressed 

A .4.4 

Low-level requirements are 
verifiable. 

■ 

■ 



Established by modeling using an executable 
language and translation to a formal specification 
language. 

A.4.5 

Low-level requirements conform 
to standards. 

□ 

□ 

□ 


Established by use of Simulink/Stateflow design 
language. 

A.4.6 

Low-level requirements are 
traceable to high-level 
requirements. 

□ 

□ 

□ 


Established by verification of the high-level 
requirements. 

A.4.7 

Algorithms are accurate. 

■ 

■ 

■ 


The accuracy of the mode logic is established by 
model checking. 

A.4.8 

Software architecture is 
compatible with high-level 
requirements. 

■ 

■ 

■ 


Established by proof that the high-level 
requirements are implemented by the low-level 
requirements and the software architecture. 

A.4.9 

Software architecture is 
consistent 

■ 

■ 

■ 


Established by modeling using an executable 
language and translation to a formal specification 
language. 

A.4.10 

Software architecture is 
compatible with target computer. 





Not addressed 

A. 4.1 1 

Software architecture is verifiable. 

■ 

■ 



Established by modeling using an executable 
language and translation to a formal specification 
language. 

A.4.12 

Software architecture conforms to 
standards. 

□ 

□ 

□ 


Partially established by use of Simulink/Stateflow. 

A.4.13 

Software partitioning integrity is 
confirmed. 





Partitioning integrity has been established using 
formal methods for several commercial operating 
systems. This is not addressed in the current case 
study. 

FM.A-4.14 

Formal analysis cases and 
procedures are correct. 

■ 

■ 

■ 


Established by review 

FM.A-4.15 

Formal analysis results are 
correct and discrepancies 
explained. 

■ 

■ 

■ 

□ 

Established by review 

FM.A-4.16 

Requirements formalization is 
correct. 

■ 

■ 

■ 


Established by review 

FM.A-4.17 

Formal method is correctly 
defined, justified, and appropriate. 

■ 

■ 

■ 

■ 

Established by review 


■ Full credit claimed □ Partial credit claimed Satisfaction of objective is at applicant’s discretion 
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Objective A-4.8 - Software architecture is compatible with the high-level requirements. This 
objective is demonstrated by proving with the JKind model checker or Design Verifier that the 
high-level software requirements are implemented by the low-level software requirements and 
the software architecture. 

Objective A-4.9 - Software architecture is consistent. This objective is met by modeling the low- 
level requirements and the software architecture in the executable modeling language 
Simulink/Stateflow and by translating that model into the formal specification language Lustre. 

Objective A-4.11 - Software architecture is verifiable. This objective is met by modeling the low- 
level requirements and the software architecture in the executable model language 
Simulink/Stateflow and by translating that model into the formal specification language Lustre. 

Objective A-4.12 - Software architecture conforms to standards. This objective is partially met by 
modeling the low-level requirements and the software architecture in the Simulink/Stateflow 
design language. Commonly used blocks are provided in a library of blocks approved for use on 
the project. Models can be automatically checked with the MATLAB Model Advisor for 
conformance with some project defined standards. Conformance to any remaining standards can 
be shown by manual review of the graphical models. 

Objective FM.A-4.14 Formal analysis cases and procedures are correct. This objective is met 
through review to ensure that the analyses and procedures satisfy the objectives A-4.1 through 
A-4.12 for which credit is claimed. There are no assumptions associated with the 
Simulink/Stateflow models to be checked. The model contains only Boolean and enumerated 
types, has only Boolean inputs and outputs, and assumes no constraints on its inputs. 

Objective FM. A-4.1 5 Formal analysis results are correct and discrepancies explained. This 
objective is met through review to ensure that all formal properties are proven. Many of the 
properties had to be revised before they could be proved. Typically, these were due to omissions 
in the original requirements or oversights introduced by the infonnality of textual requirements. 
For example, the requirement that “vertical approach mode shall be active only if lateral 
approach mode is active” could not be implemented with the chosen software architecture and 
had to be relaxed to allow lateral approach mode to be inactive for a single step before vertical 
approach mode became inactive. Each such requirement change or discrepancy was explained 
and fed back into the safety assessment process for review. 
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Objective FM.A-4.16 Requirements formalization is correct. This objective is met through review to 
ensure that the fonnal statement of a requirement is a conservative representation of the infonnal 
requirement. In the case where the JKind model checker is used for verification, the translation 
of the Simulink/Stateflow model to Lustre must either be checked by review or by qualification 
of the translation tool. 

Objective FM.A-4.17 Formal method is correctly defined, justified, and appropriate. This objective 
is met through a review to ensure: 

a. All notations used for fonnal analysis are verified to have precise, unambiguous, 
mathematically defined syntax and semantics. The fonnal notation used was a subset of 
Simulink/Stateflow that was automatically translated to the Lustre formal specification 
language. 

b. The soundness of each formal analysis method is justified. The JKind model checker is 
based k-induction, as is the Kind model checker upon which it is based. Soundness of k- 
induction is straightforward and is discussed in [9] and its references. Since the Design 
Verifier model checker is a commercial product, less infonnation is available about the 
underlying methodology. Soundness concerns would have to be addressed by the vendor 
as part of a qualification support kit. 

c. Assumptions related to each formal analysis are described and justified. Since this 
example contains only Boolean and enumerated types, no assumptions related to the 
formal analysis (e.g., approximating floating-point numbers as reals) were necessary. 

4.2.4 Tool Qualification Issues 

As was the case for the theorem proving case study, for the certification objectives and mode of 
tool use that we are considering in this case study, Criteria 3 applies. This means that for all 
airborne software levels the model checkers would need to be qualified to TQL-5. Model 
checking does not (in general) produce independently checkable output. This means that the 
model checker must be qualified if its outputs are to be used for certification credit. 

In addition to the development artifacts that must be provided, tool qualification requires that 
Tool Operational Requirements (TOR) be defined. The TORs describe what the tool claims to 
do relative to the certification objectives. Then a comprehensive test suite must be developed to 
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show that those requirements are satisfied over an appropriate range of tool inputs. For a model 
checker, this would mean producing a collection of models and properties that span the full range 
of constructs found in the model and property specification language(s) of the tool. These 
example models would need to contain property errors which the model checker would have to 
be shown to identify correctly. 

We are not aware of any existing efforts to qualify an academic open source model checker like 
Kind. However, there is no reason that this could not be accomplished following the process 
outlined above, in a manner similar to that carried out for any other TQL-5 verification tool. 

Our use of Kind relied upon the Rockwell Collins translation framework to generate Lustre input 
from the Simulink/Stateflow model. There are two ways that this might be handled with respect 
to certification/qualification concerns. The first approach would be to consider the translation 
tool and the model checker to be a single tool that acts directly on the Simulink/Stateflow model 
and doesn’t directly expose the intennediate Lustre translation. The TORs and qualification test 
suite would be written to be consistent with this interface. The second approach would be to 
consider the translation and model checking steps separately. The model checker would be 
qualified on its own based on the Lustre input language. The translation step would then be 
treated as part of the Low-Level Requirements formalization process (Objective FM.A-4.16). 
The objective would be to show that the Lustre output is a conservative representation of the 
Simulink/Stateflow input model. This could be satisfied either through a manual review of the 
input and output, or by qualification of the translation tool to automate this function. 

For commercial tools like Simulink Design Verifier, some support from the tool vendor may be 
needed to achieve qualification. As of this time, MathWorks has not provided a qualification kit 
for the Design Verifier. However, there is no reason in principle, that this could not be done. 
The general outline of qualification should be similar to that of the Polyspace abstract 
interpretation tool (described in section 5.2.3 and [19]). 

4.3 Specification of the Mode Logic 

This section describes the mode logic in detail as a MATLAB Simulink/Stateflow model. The 
top level Simulink diagram is shown in Figure 79. 
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Figure 79 - Mode Logic Top Level 

As can be seen in Figure 79, the mode logic takes several Boolean valued inputs and outputs 
several Boolean values summarizing the status of the system modes. The mode logic has two 
subsystems, Event Processing and Flight Modes. Event Processing outputs Boolean events 
(signals that are true for at most one step) and Boolean conditions (signals that can be true for 
several steps). It establishes a priority among the incoming events and conditions and ensures 
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that if multiple events or conditions occur on the same step, only the higher priority events and 
conditions are output to the Flight Modes. Event Processing is discussed in more detail in 
Section 4.3.2. 

4.3.1 Flight Modes 

The Flight Modes subsystem of Figure 79 is the heart of the mode logic. As shown in Figure 80, 
it is organized into four parallel state machines, FD, ANNUNCIATIONS, LATERAL, and 
VERTICAL, 

( 1 
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ANNUNCIATIONS 
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Figure 80 - Flight Modes Subsystem 

These four state machines execute in the order indicated by the number in each state machine in 
Figure 80. The FD state machine determines whether the FD is displayed on the PFD, while the 
ANNUNCIATIONS state machine determines whether the mode annunciations are displayed on 
the PFD. The LATERAL and VERTICAL state machines are further decomposed into the state 
machines for the lateral and vertical modes of the FGS. 
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4.3.1. 1 FD 

The FD state machine determines whether the FD associated with this FGS channel is displayed 
on the PFD. Its logic is shown in Figure 81. 


FD 



Figure 81 - FD Mode Logic 

The FD is either OFF or ON and always starts in the OFF state. Whether the FD transitions from 
the OFF state to the ON state is determined by the Turn FD On truth table shown in Table 3. As 
specified in that table, the FD should be turned on if the FD switch is pressed, the AP is engaged, 
an overspeed condition exists, a lateral mode is manually selected, a vertical mode is manually 
selected, or there is a pilot flying transfer to this side of the aircraft while the mode annunciations 
are on. 


Table 3 - Turn FD On 


Condition 

1 

2 

3 

4 

5 

6 

7 

FD Switch Pressed 

T 

- 

- 

- 

- 

- 

- 

When AP Engaged 

- 

T 

- 

- 

- 

- 

- 

Overspeed 

- 

- 

T 

- 

- 

- 

- 

Lateral Mode Manually Selected!) 

- 

- 

- 

T 

- 

- 

- 

Vertical Mode Manually Selected!) 

- 

- 

- 

- 

T 

- 

- 

Pilot Flying Transfer 

- 

- 

- 

- 

- 

T 

- 

Pilot Flying Side 

- 

- 

- 

- 

- 

T 

- 

Modes On 

- 

- 

- 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


Note that the FD state machine sets the mode logic output FD On of the mode logic to true when 
it enters the ON state and to false when it exits the ON state. All of the FGS outputs are turned 
on and off in similar fashion by other state machines. 
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The truth table for when a lateral mode is manually selected is shown in Table 4. A lateral mode 
is manually selected when the HDG, NAY, APPR, or GA switch is pressed. 


Table 4 - Lateral Mode Manually Selected 


Condition 

1 

2 

3 

4 

5 

HDG Switch Pressed 

T 

- 

- 

- 

- 

NAV Switch Pressed 

- 

T 

- 

- 

- 

APPR Switch Pressed 

- 

- 

T 

- 

- 

GA Switch Pressed 

- 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


The truth table for when a vertical mode is manually selected is shown in Table 5. A vertical 
mode is manually selected when the VS, FLC, ALT, APPR, or GA switch is pressed or when the 
VS Pitch Wheel is rotated while Vertical Speed (VS) and Vertical Approach (VAPPR) modes 
are not active and an overspeed condition does not exist. 


Table 5 - Vertical Mode Manually Selected 


Condition 

1 

2 

3 

4 

5 

6 

7 

VS Switch Pressed 

T 

- 

- 

- 

- 

- 

- 

FLC Switch Pressed 

- 

T 

- 

- 

- 

- 

- 

ALT Switch Pressed 

- 

- 

T 

- 

- 

- 

- 

APPR Switch Pressed 

- 

- 

- 

T 

- 

- 

- 

GASwitchPressed 

- 

- 

- 

- 

T 

- 

- 

VS Pitch Wheel Rotated 

- 

- 

- 

- 

- 

T 

- 

VS_Active 

- 

- 

- 

- 

- 

F 

- 

VAPPR Active 

- 

- 

- 

- 

- 

F 

- 

Overspeed 

- 

- 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


The conditions for turning the FD off are show in Table 6. The FD should be turned off when 
the FD switch is pressed provided an overspeed condition does not exist. 

Table 6 - Turn FD Off 


Condition 

1 

2 

FD Switch Pressed 

T 

- 

Overspeed 

F 

- 


TRUE 

FALSE 
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4.3.1. 2 ANNUNCIATIONS 

The ANNUNCIATIONS state machine determines whether the mode annunciations are 
displayed on the PFD. Its logic is shown in Figure 82. 
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Figure 82 - ANNUNCIATIONS Mode Logic 

The mode annunciations are either OFF or ON and always start in the OFF state. Whether the 
annunciations are displayed is determined by the Turn Annunciations On truth table shown in 
Table 7. The mode annunciations are turned on whenever the AP is engaged, the offside FD (i.e., 
the FD on the other side of the aircraft) is turned on, or the FD on this side of the aircraft is 
turned on. 


Table 7 - Turn Annunciations On 


Condition 

1 

2 

3 

4 

Is AP Engaged 

T 

- 

- 

- 

Is Offside FD On 

- 

T 

- 

- 

FDOn 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

FALSE 


The logic for turning the mode annunciations off is given in the truth table of Table 8. The mode 
annunciations are turned off when the AP is not engaged, the offside FD is not displayed, and the 
onside FD is not displayed. 


Table 8 - Turn Annunciations Off 


Condition 

1 

2 

Is AP Engaged 

F 

- 

Is Offside FD On 

F 

- 

FDOn 

F 

- 
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Actions TRUE FALSE 


4.3.1. 3 LATERAL 

The lateral modes control the behavior of the aircraft about the longitudinal, or roll, axis. The 
organization of the LATERAL state machine is shown in Figure 83. 

LATERAL 

Update_Activated_Modes 


HDG 


NAV 


LAPPR 


ROLL 


Lateral_Mode_Active 
New Lateral Mode Activated 


Figure 83 - LATERAL Modes 

The individual lateral modes of HDG, NAV, LAPPR, LGA, and ROLL are implemented as 
parallel state machines that execute in the order shown in Figure 83. Since exactly one lateral 
mode should be active and providing guidance to the FD and AP at a time, the LATERAL state 
machine defines two truth tables, Lateral _Mode_Active and New _Lateral _Mode_Activated, and 
a function, Update _Activated_Modes, to support this synchronization. 
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The Lateral _Mode _Active truth table is used to make the default lateral mode Roll Hold (ROLL) 
active if no other lateral mode is active and to deactivate ROLL mode when another lateral mode 
becomes active. Its specification is given in the description of ROLL mode in Section 4.3. 1.3.5. 

The New -Lateral _Mode_Activated truth table is used to deactivate the active lateral mode when 
a new lateral mode becomes active. Its logic is shown in Table 9. 


Table 9 - New Lateral Mode Activated 


Condition 

1 

2 

3 

4 

5 

HDG Will Be Activated 

T 

- 

- 

- 

- 

NAV Will Be Activated 

- 

T 

- 

- 

- 

LAPPR Will Be Activated 

- 

- 

T 

- 

- 

LGA Will Be Activated 

- 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


While the intent of New -Lateral _Mode -Activated is straightforward - it should return true if a 
new lateral mode will be activated during this step - its implementation is actually quite subtle. 
Invoking it during the execution of the currently active mode to determine if that mode should 
deactivate may depend on whether a mode that has not yet executed will become active. The 
recommended way to synchronize parallel state machines in Stateflow is to “wake-up” a mode 
machine that executed earlier through the use of directed broadcast events. Unfortunately, this 
leads to a model that is not well-suited for model checking. 5 

Instead, we require that each mode implements a truth table Will _Be_Activated that predicts if 
that mode will become active based on its current state and its inputs. At the start of each step of 
the LATERAL mode machine, these values are computed and stored in local state variables by 
the Update -Activated _Modes function. These stored values are then used in the 
New_Lateral _Mode -Activated truth table shown in Table 9 so that the current active lateral 
mode knows whether to deactivate itself regardless of its order of execution. 


5 For model checking, the state transition relation must be “unwound” into a static description of all possible system 
transitions. Each directed broadcast significantly increases the complexity of this description and the interleaving of 
all possible sequences of directed broadcasts results in a combinatorial explosion in the size of the state transition 
relation. 
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4.3. 1.3.1 Heading Select (HDG) 

Heading Select (HDG) mode turns the aircraft to the selected heading displayed on the PFD and 
then holds the aircraft to that heading. It is a non-arming mode that can be selected to become the 
active lateral mode at any time. Its logic is shown in Figure 84. 

HDG 



Figure 84 - Heading Select (HDG) Mode 

HDG mode starts in the CLEARED state. It transitions into the SELECTED state when the 
HDGSelect truth table shown in Table 10 evaluates to true, i.e., when the HDG switch is 
pressed. On entry to the SELECTED state it sets the HDG Selected output to true. 

Table 10 -HDG Select 


Condition 

1 

2 

HDG Switch Pressed 

T 

- 


TRUE 

FALSE 


Since it is not an arming mode, it immediately transitions into the ACTIVE state. On entry to the 
ACTIVE state it sets the HDG Active output to true. HDG mode returns to the CLEARED state 
when the HDG Clear truth table shown in Table 1 1 evaluates to true, i.e., when the HDG 
switch is pressed, when there is a pilot flying transfer, or when the mode annunciations are 
turned off. Note that on exit from the ACTIVE state it sets the HDG Active output to false and 
on exit from the SELECTED state it sets the HDG Selected output to false. 
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Table 11 - HDG Clear 


Condition 

1 

2 

3 

4 

HDG Switch Pressed 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

T 

- 

- 

Modes On 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

FALSE 


HDG mode will also transition to the CLEARED state if another mode becomes active on this 
step (i.e., the transition guarded by New _Lateral _Mode -Activated is taken). In similar fashion, if 
HDG mode becomes active, the current active lateral mode must deactivate itself. The 
Will Be -Activated truth table that supports this synchronization for HDG mode is shown in 
Table 12. 


Table 12 - HDG Will Be Activated 


Condition 

1 

2 

in(CLEARED) 

T 

- 

SelectQ 

T 

- 


TRUE 

FALSE 


4.3.1. 3.2 Lateral Navigation (NAV) 

Lateral Navigation (NAV) mode captures and tracks lateral guidance for en route navigation and 
non-precision approaches. It is an anning mode that must be armed before it can become active. 
Its logic is shown in Figure 85. 

NAV 



Figure 85 - Lateral Navigation (NAV) Mode 
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NAV mode starts in the CLEARED state. It transitions into the SELECTED state when the 
NAV_Select truth table shown in Table 13 evaluates to true, i.e., when the NAV switch is 
pressed. 


Table 13 -NAV Select 


Condition 

1 

2 

NAV Switch Pressed 

T 

- 


TRUE 

FALSE 


Since it is an arming mode, it then enters the ARMED state. From the ARMED state it will 
transition to the ACTIVE state when the NAV_Capture truth table shown in Table 14 evaluates 
to true, i.e. when the NA V_Capture_Condition_Met input is true. 


Table 14 - NAV Capture 


Condition 

1 

2 

NAV Capture Condition Met 

T 

- 


TRUE 

FALSE 


NAV mode returns to the CLEARED state when the NAV_Clear truth table shown in Table 15 
evaluates to true, i.e., when the NAV switch is pressed, when the navigation source or frequency 
changes, when there is a pilot flying transfer, or when the mode annunciations are turned off. 

Table 15- NAV Clear 


Condition 

1 

2 

3 

4 

5 

6 

NAV Switch Pressed 

T 

- 

- 

- 

- 

- 

Selected_NAV_Source_Changed 

- 

T 

- 

- 

- 

- 

Selected NAV Frequency Changed 

- 

- 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

- 

T 

- 

- 

Modes On 

- 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


NAV mode will also transition to the CLEARED state if another mode becomes active on this 
step (i.e., the transition guarded by New _Lateral_Mode -Activated is taken). Note that it is not 
possible to directly transition back to the ARMED state from the ACTIVE state. The 
Will Be Activated truth table for NAV mode is shown in Table 16. 
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Table 16 - NAV Will Be Activated 


Condition 

1 

2 

in( SELECTED. ARMED) 

T 

- 

Capture() 

T 

- 

ClearQ 

F 

- 


TRUE 

FALSE 


Note that since NAV is an anning mode, Table 16 must guard against the situation in which 
NAV mode receives a command to clear itself at the same time that its capture condition 
becomes true. 

4.3.1. 3.3 Lateral Approach (LAPPR) 

Lateral Approach (LAPPR) mode captures and tracks lateral guidance for precision and non- 
precision approaches. It is an arming mode that must be armed before it can become active. Its 
logic is shown in Figure 86. 

LAPPR 



Figure 86 - Lateral Approach (LAPPR) Mode 

LAPPR mode starts in the CLEARED state. It transitions into the SELECTED state when the 
LAPPRSelect truth table shown in Table 17 evaluates to true, i.e., when the APPR switch is 
pressed. 

Table 17 - LAPPR Select 


Condition 

1 

2 

APPR Switch Pressed 

T 

- 


TRUE 

FALSE 
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Since it is an arming mode, it then enters the ARMED state. From the ARMED state it will 
transition to the ACTIVE state when the LAPPRCapture truth table shown in Table 18 
evaluates to true, i.e. when the LAPPR_Capture_Condition_Met input is true. 


Table 18 - LAPPR Capture 


Condition 

1 

2 

LAPPR Capture Condition Met 

T 

- 


TRUE 

FALSE 


LAPPR mode returns to the CLEARED state when the LAPPR Clear truth table shown in Table 
19 evaluates to true, i.e., when the APPR switch is pressed, when the navigation source or 
frequency is changed, when there is a pilot flying transfer, or when the mode annunciations are 
turned off. 


Table 19 - LAPPR Clear 


Condition 

1 

2 

3 

4 

5 

6 

APPR Switch Pressed 

T 

- 

- 

- 

- 

- 

Selected_NAV_Source_Changed 

- 

T 

- 

- 

- 

- 

Selected_NAV_Frequency_Changed 

- 

- 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

- 

T 

- 

- 

Modes On 

- 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


LAPPR mode will also transition to the CLEARED state if another mode becomes active on this 
step (i.e., the transition guarded by New _Lateral_Mode Activated is taken). Note that it is not 
possible to directly transition back to the ARMED state from the ACTIVE state. The 
Will Be Activated truth table for LAPPR mode is shown in Table 20. 


Table 20 - LAPPR Will Be Activated 


Condition 

1 

2 

in( SELECTED. ARMED) 

T 

- 

Capture!) 

T 

- 

Clear() 

F 

- 


TRUE 

FALSE 
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4.3. 1.3.4 Lateral Go Around (LGA) 

Lateral Go Around (LGA) mode maintains the current heading when the pilot aborts a landing. It 
is a non-arming mode that can become the active lateral mode at any time. Its logic is shown in 
Figure 87. 

LGA 



Figure 87 - Lateral Go Around (LGA) Mode 

LGA mode starts in the CLEARED state. It transitions into the SELECTED state when the 
LGA_Select truth table shown in Table 21 evaluates to true, i.e., when the GA switch is pressed 
while an overspeed condition does not exist. 

Table 21 - LGA Select 


Condition 

1 

2 

GA Switch Pressed 

T 

- 

Overspeed 

F 

- 


TRUE 

FALSE 


Since it is not an arming mode, it immediately transitions into the ACTIVE state. LGA mode 
returns to the CLEARED state when the LGA Clear truth table shown in Table 22 evaluates to 
true, i.e., when the AP is engaged, when the SYNC switch is pressed, when Vertical Go Around 
(VGA) mode becomes inactive, when there is a pilot flying transfer, or when the mode 
annunciations are turned off. 
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Table 22 - LGA Clear 


Condition 

1 

2 

3 

4 

5 

6 

When AP Engaged 

T 

- 

- 

- 

- 

- 

SYNC Switch Pressed 

- 

T 

- 

- 

- 

- 

VGA Active 

- 

- 

F 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

- 

T 

- 

- 

ModesOn 

- 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


LGA mode will also transition to the CLEARED state if another mode becomes active on this 
step (i.e., the transition guarded by New _Lateral _Mode -Activated is taken). The 
Will Be Activated truth table for LGA mode is shown in Table 23. 


Table 23 - LGA Will Be Activated 


Condition 

1 

2 

in(CLEARED) 

T 

- 

SelectQ 

T 

- 


TRUE 

FALSE 


4.3.1. 3.5 Roll Hold (ROLL) 

Roll Hold (ROLL) mode holds the aircraft at the fixed ha nk angle it is in when the mode 
becomes active or when the SYNC switch is pressed. ROLL mode is the basic lateral mode and 
is always active when no other lateral mode is active and the mode annunciations are on. Since it 
may need to become active at any time, it a non-arming mode. Its logic is shown in Figure 88. 


ROLL 



Figure 88 - Roll Hold (ROLL) 

ROLL mode starts in the Active state. It transitions into the CLEARED state when the Lateral 
Mode Active truth table shown in Table 24 evaluates to true, i.e., when another lateral mode is 
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active. ROLL mode transitions back to the ACTIVE state when no other lateral mode is active, 
i.e. when Lateral _Mode_Active evaluates to false. 

Table 24 - Lateral Mode Active 


Condition 

1 

2 

3 

4 

5 

HDG Active 

T 

- 

- 

- 

- 

NAV Active 

- 

T 

- 

- 

- 

LAPPR Active 

- 

- 

T 

- 

- 

LGA Active 

- 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


4.3.1. 4 VERTICAL 

The vertical modes control the behavior of the aircraft about the lateral, or pitch, axis. The 
organization of the VERTICAL state machine is shown in Figure 89. 

The individual vertical modes of VS, FLC, ALT, ALTSEL, VAPPR, VGA and PITCH are 
implemented as parallel state machines that execute in that order. Just as with the lateral modes, 
the VERTICAL state machine defines two truth tables, Vertical _Mode_Active and 
New_Vertical_Mode_Activated, and a function, Update_Activated_Modes, to support the 
synchronization between the vertical modes. 

The Vertical _Mode_Active truth table is used to make the default vertical mode Pitch Hold 
(PITCH) active if no other vertical mode is active and to deactivate PITCH mode when another 
vertical mode becomes active. Its specification is given in the description of PITCH mode in 
Section 4.3. 1.4.7. 
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FLC 
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Vertical Mode Active 


New Vertical Mode Activated 


Figure 89 - VERTICAL Modes 

The New_Vertical_Mode_Activated truth table is used to deactivate the current active vertical 
mode when a new vertical mode becomes active. Its logic is shown in Table 25. 
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Table 25 - New Vertical Mode Activated 


Condition 

1 

2 

3 

4 

5 

6 

7 

VS Will Be Activated 

T 

- 

- 

- 

- 

- 

- 

FLC Will Be Activated 

- 

T 

- 

- 

- 

- 

- 

ALT Will Be Activated 

- 

- 

T 

- 

- 

- 

- 

ALTSEL Will Be Activated 

- 

- 

- 

T 

- 

- 

- 

VAPPR Will Be Activated 

- 

- 

- 

- 

T 

- 

- 

VGA Will Be Activated 

- 

- 

- 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


As with the lateral modes, we require that each vertical mode implements a truth table 
Will Be -Activated that predicts if that mode will become active based on its current state and its 
inputs. At the start of each step of the VERTICAL mode machine, these values are computed and 
stored in local state variables by the Update -Activated Modes function. These stored values are 
then used in the New _Vertical _Mode_Activated truth table shown in Table 25 so that the current 
active vertical mode knows whether to deactivate itself if another vertical mode will become 
active. 

4.3.1. 4.1 Vertical Speed (VS) 

Vertical Speed (VS) mode holds the aircraft to the Vertical Speed (VS) reference displayed on 
the PFD. It is a non- arming mode that can become active at any time. Its logic is shown in 
Figure 90. 

vs 



Figure 90 - Vertical Speed (VS) Mode 
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VS mode starts in the CLEARED state. It transitions into the SELECTED state when the 
VS_Select truth table shown in Table 26 evaluates to true, i.e., when the VS switch is pressed 
while an overspeed condition does not exist and Vertical Approach (VAPPR) mode is not active. 

Table 26 -VS Select 


Condition 

1 

2 

V SSwitchPressed 

T 

- 

Overspeed 

F 

- 

VAPPR Active 

F 

- 


TRUE 

FALSE 


Since it is not an anning mode, it immediately transitions into the ACTIVE state. VS mode 
returns to the CLEARED state when the VS Clear truth table shown in Table 27 evaluates to 
true, i.e., when the VS switch is pressed, when there is a pilot flying transfer, or when the mode 
annunciations are turned off. 


Table 27 -VS Clear 


Condition 

1 

2 

3 

4 

VS Switch Pressed 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

T 

- 

- 

Modes On 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

FALSE 


VS mode will also transition to the CLEARED state if another vertical mode becomes active on 
this step (i.e., the transition guarded by New_Vertical_Mode_Activated is taken). The 
WUl_Be_Activated truth table for VS is shown in Table 28. 

Table 28 - VS Will Be Activated 


Condition 

1 

2 

in(CLEARED) 

T 

- 

SelectQ 

T 

- 


TRUE 

FALSE 
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4.3.1. 4.2 Flight Level Change (FLC) 

Flight Level Change (FLC) mode acquires and tracks an Indicated Airspeed (IAS) or Mach 
Reference Airspeed while also climbing or descending to bring the aircraft to the Preselected 
Altitude. It is a non-arming mode that can become active at any time. Its logic is shown in 
Figure 91. 

FLC 



Figure 91 - Flight Level Change (FLC) Mode 

FLC mode starts in the CLEARED state. It transitions into the SELECTED state when the 
FLCSelect truth table shown in Table 29 evaluates to true, i.e., when the FLC switch is pressed 
while Vertical Approach (VAPPR) mode is not active, or when an overspeed condition exists 
while Altitude Hold (ALT) mode and Altitude Select (ALTSEL) mode are not active and are not 
about to become active. 


Table 29 - FLC Select 


Condition 

1 

2 

3 

FLC Switch Pressed 

T 

- 

- 

VAPPR Active 

F 

- 

- 

Overspeed 

- 

T 

- 

ALT Active 

- 

F 

- 

ALT Will Be Activated 

- 

F 

- 

ALTSEL Active 

- 

F 

- 

ALTSEL Will Be Activated 

- 

F 

- 


TRUE 

TRUE 

FALSE 


Since it is not an arming mode, it immediately transitions into the ACTIVE state. FLC mode 
returns to the CLEARED state when the FLC Clear truth table shown in Table 30 evaluates to 
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true, i.e., when the FLC switch is pressed while there is not an overspeed condition, when the VS 
Pitch Wheel is rotated while there is not an overspeed condition, when there is a pilot flying 
transfer, or when the mode annunciations are turned off. 

Table 30 -FLC Clear 


Condition 

1 

2 

3 

4 

5 

FLC Switch Pressed 

T 

- 

- 

- 

- 

Overspeed 

F 

F 

- 

- 

- 

VS Pitch Wheel Rotated 

- 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

T 

- 

- 

Modes On 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


FLC mode will also transition to the CLEARED state if another vertical mode becomes active on 
this step (i.e., the transition guarded by New _Vertical_Mode -Activated is taken). The 
Will Be -Activated truth table for FLC is shown in Table 3 1 . 

Table 31 - FLC Will Be Activated 


Condition 

1 

2 

in(CLEARED) 

T 

- 

SelectQ 

T 

- 


TRUE 

FALSE 


4.3.1. 4.3 Altitude Hold (ALT) 

Altitude Hold (ALT) mode acquires and tracks the altitude reference, which is set to the current 
altitude when the mode is activated or upon a SYNC request by the flight crew. It is a non- 
arming mode that can become active at any time. Its logic is shown in Figure 92. 
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Figure 92 - Altitude Hold (ALT) Mode 

ALT mode starts in the CLEARED state. It transitions into the SELECTED state when the 
ALT_SeIect truth table shown in Table 32 evaluates to true, i.e., when the ALT switch is pressed 
while Vertical Approach (VAPPR) mode is not active or when the Altitude Select (ALTSEL) 
target altitude is changed while ALTSEL mode is in the TRACK state and VAPPR mode is not 
active. 


Table 32 - ALT Select 


Condition 

1 

2 

3 

ALT Switch Pressed 

T 

- 

- 

VAPPR Active 

F 

F 

- 

ALTSEL Target Changed 

- 

T 

- 

ALTSELTrack 

- 

T 

- 


TRUE 

TRUE 

FALSE 


Since it is not an anning mode, it immediately transitions into the ACTIVE state. ALT mode 
returns to the CLEARED state when the ALT_Clear truth table shown in Table 33 evaluates to 
true, i.e., when the ALT switch is pressed, when the VS Pitch Wheel is rotated, when there is a 
pilot flying transfer, or when the mode annunciations are turned off. 
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Table 33 -ALT Clear 


Condition 

1 

2 

3 

4 

5 

ALT Switch Pressed 

T 

- 

- 

- 

- 

VS Pitch Wheel Rotated 

- 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

T 

- 

- 

Modes On 

- 

- 

- 

F 

- 

Actions 

TRUE TRUE 

TRUE 

TRUE FALSE 


ALT mode will also transition to the CLEARED state if another vertical mode becomes active 
on this step (i.e., the transition guarded by New_Vertical_Mode_Activated is taken). The 
Will Be -Activated truth table for ALT is shown in Table 34. 

Table 34 - ALT Will Be Activated 


Condition 

1 

2 

in(CLEARED) 

T 

- 

SelectQ 

T 

- 


TRUE 

FALSE 


4.3.1. 4.4 Altitude Select (ALTSEL) 

Altitude Select (ALTSEL) mode captures and tracks the Preselected Altitude. It is a capture/track 
mode that must be anned before it can become active and that has both capture and track sub- 
states of its active state. Its logic is shown in Figure 93. 


ALTSEL 



Figure 93 - Altitude Select (ALTSEL) Mode 
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ALTSEL starts in the CLEARED state. It transitions to the SELECTED state when the 
ALTSEL Select truth table shown in Table 35 evaluates to true, i.e., when none of Vertical 
Approach (VAPPR), Vertical Go Around (VGA), or Altitude Hold (ALT) mode are active. 

Table 35 - ALTSEL Select 


Condition 

1 

2 

VAPPR Active 

F 

- 

VGA Active 

F 

- 

ALT Active 

F 

- 


TRUE 

FALSE 


It also immediately enters the ARMED state in which the FGS monitors the aircraft closure rate 
towards the target altitude and detennines the optimum capture point to transition to the capture 
state. When the ALTSEL capture condition is met (Table 36) it enters the ACTIVE state. 


Table 36 - ALTSEL Capture 


Condition 

1 

2 

ALTSEL Capture Condition Met 

T 

- 

Actions 

TRUE FALSE 


It also immediately enters the CAPTURE state in which the FGS generates vertical guidance 
commands to perfonn a smooth capture of the target altitude. Once the target altitude is reached 
and the ALTSEL track condition is met (Table 37) it transitions to the TRACK state. 


Table 37 - ALTSEL Track 


Condition 

1 

2 

ALTSEL Track Condition Met 

T 

- 


TRUE 

FALSE 


ALTSEL mode returns to the CLEARED state when the ALTSEL Clear truth table shown in 
Table 38 evaluates to true, i.e., when one of Vertical Approach (VAPPR), Vertical Go Around 
(VGA), or Altitude Hold (ALT) modes becomes active, or when the mode annunciations are 
turned off. 
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Table 38 -ALTSEL Clear 


Condition 

1 

2 

3 

4 5 

VAPPR Active 

T 

- 

- 

- 

VGA Active 

- 

T 

- 

- 

ALT Active 

- 

- 

T 

- 

Modes On 

- 

- 

- 

F 

Actions 

TRUE 

TRUE TRUE 

TRUE FALSE 


ALTSEL mode will also transition to the CLEARED state if another mode becomes active on 
this step (i.e., the transition guarded by New_Vertical_Mode_Activated is taken). The 
Will Be Activated truth table for ALTSEL mode is shown in Table 39. 


Table 39 - ALTSEL Will Be Activated 


Condition 

1 

2 

in( SELECTED. ARMED) 

T 

- 

Capture() 

T 

- 

Clear() 

F 

- 


TRUE 

FALSE 


4.3. 1.4.5 Vertical Approach (VAPPR) 

Vertical Approach (VAPPR) mode captures and tracks the vertical guidance for Instrument 
Landing System (ILS) precision glideslope approaches. It is an anning mode that must be anned 
before it can become active. Its logic is shown in Figure 94. 

VAPPR 



Figure 94 - Vertical Approach (VAPPR) Mode 
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VAPPR mode starts in the CLEARED state. It transitions into the SELECTED state when the 
VAPPR_Select truth table shown in Table 40 evaluates to true, i.e., when the APPR switch is 
pressed. 


Table 40 -VAPPR Select 


Condition 

1 

2 

APPR Switch Pressed 

T 

- 


TRUE 

FALSE 


It also immediately enters the ARMED state. From the ARMED state it will transition to the 
ACTIVE state when the VAPPR Capture truth table shown in Table 41 evaluates to true, i.e., 
when the vertical approach capture condition is met and Lateral Approach (LAPPR) mode is 
active and an overspeed condition does not exist. 


Table 41 - VAPPR Capture 


Condition 

1 

2 

VAPPR Capture Condition Met 

T 

- 

LAPPR Active 

T 

- 

Overspeed 

F 

- 


TRUE 

FALSE 


VAPPR mode returns to the CLEARED state when the VAPPR Clear truth table shown in 
Table 42 evaluates to true, i.e., when the APPR switch is pressed, when Lateral Approach 
(LAPPR) mode is not selected, when the navigation source or frequency is changed, when there 
is a pilot flying transfer, or when the mode annunciations are turned off. 

Table 42 -VAPPR Clear 


Condition 

1 

2 

3 

4 

5 

6 

7 

APPR Switch Pressed 

T 

- 

- 

- 

- 

- 

- 

LAPPRSelected 

- 

F 

- 

- 

- 

- 

- 

Selected_NAV_Source_Changed 

- 

- 

T 

- 

- 

- 

- 

Selected NAV Frequency Changed 

- 

- 

- 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

- 

- 

T 

- 

- 

Modes On 

- 

- 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 
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VAPPR mode will also transition to the CLEARED state if another mode becomes active on this 
step (i.e., the transition guarded by New_Vertical_Mode_Activated is taken). The 
Will Be Activated truth table for VAPPR mode is shown in Table 43. 


Table 43 - VAPPR Will Be Activated 


Condition 

1 

2 

in( SELECTED . ARMED) 

T 

- 

Capture() 

T 

- 

ClearQ 

F 

- 


TRUE 

FALSE 


4.3.1. 4.6 Vertical Go Around (VGA) 

Vertical Go Around (VGA) mode maintains a fixed pitch angle when the pilot aborts a landing. 
It is a non-arming mode that can become the active vertical mode at any time. Its logic is shown 
in Figure 95. 

VGA 



Figure 95 - Vertical Go Around (VGA) Mode 

VGA mode starts in the CLEARED state. It transitions into the SELECTED state when the 
VGA_Select truth table shown in Table 44 evaluates to true, i.e., when the GA switch is pressed 
while an overspeed condition does not exist. 
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Table 44 - VGA Select 


Condition 

1 

2 

GA Switch Pressed 

T 

- 

Overspeed 

F 

- 

Actions 

TRUE FALSE 


It immediately transitions into the ACTIVE state. VGA mode returns to the CLEARED state 
when the VGA Clear truth table shown in Table 45 evaluates to true, i.e., when the AP is 
engaged, when the SYNC switch is pressed, when the VS Pitch Wheel is rotated, when there is a 
pilot flying transfer, or when the mode annunciations are turned off. 

Table 45 -VGA Clear 


Condition 

1 

2 

3 

4 

5 

6 

When AP Engaged 

T 

- 

- 

- 

- 

- 

SYNC Switch Pressed 

- 

T 

- 

- 

- 

- 

VS Pitch Wheel Rotated 

- 

- 

T 

- 

- 

- 

Pilot Flying Transfer 

- 

- 

- 

T 

- 

- 

Modes On 

- 

- 

- 

- 

F 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


LGA mode will also transition to the CLEARED state if another mode becomes active on this 
step (i.e., the transition guarded by New_Vertical_Mode_Activated is taken). The 
Will Be -Activated truth table for LGA mode is shown in Table 23. 

Table 46 - LGA Will Be Activated 


Condition 

1 

2 

in(CLEARED) 

T 

- 

SelectQ 

T 

- 


TRUE 

FALSE 


4.3.1. 4.7 Pitch Hold (PITCH) 

Pitch Hold (PITCH) mode holds the aircraft at the fixed pitch angle it is in when the mode 
becomes active or when the SYNC switch is pressed. PITCH is the basic vertical mode and is 
always active when no other vertical mode is active. Since it may need to become active at any 
time, it is a non-arming mode. Its mode logic is shown in Figure 96. 
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SELECTED 

en: PITCH_Selected = true 
ex: PITCH Selected = false 



[ ! Vertical_Mode_Active()] 


ACTIVE 

en: PITCH_Active = true 
ex: PITCH_Active = false 



[Vertical_Mode_Active()] 





^ j 





J 


Figure 96 - Pitch Hold (PITCH) Mode 

PITCH mode starts in the Active sub-state of the SELECTED state. It transitions into the 
CLEARED state when the Vertical _Mode_Active truth table shown in Table 47 evaluates to true, 
i.e., when another vertical mode is active. PITCH mode transitions back to the ACTIVE state 
when no other vertical mode is active, i.e. when Vertical _Mode_Active evaluates to false. 

Table 47 - Vertical Mode Active 


Condition 

1 

2 

3 

4 

5 

6 

7 

VS_Active 

T 

- 

- 

- 

- 

- 

- 

FLC Active 

- 

T 

- 

- 

- 

- 

- 

ALT Active 

- 

- 

T 

- 

- 

- 

- 

ALTSEL Active 

- 

- 

- 

T 

- 

- 

- 

VAPPR Active 

- 

- 

- 

- 

T 

- 

- 

VGA Active 

- 

- 

- 

- 

- 

T 

- 


TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

TRUE 

FALSE 


4.3.2 Event Processing 

While the Flight Modes subsystem of Section 4.3.1 constitutes most of the mode logic, the Event 
Processing subsystem also plays an important role. The LATERAL and VERTICAL state 
diagrams ensure that there is always at least one lateral and one vertical mode active, and that the 
current active lateral or vertical mode is always deactivated if a new mode becomes active. 
However, they do not ensure that only one lateral and one vertical mode is active at the same 
time. In fact, without Event Processing there are several situations in which more than one lateral 
or vertical mode can become active. The next section describes the approach taken here - 
prioritization of input events - to keep this from happening. Other approaches and the reasons for 
not selecting them are discussed in Section 4.3.2. 1. 
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4.3.2. 1 Event Prioritization 


The logic of the Event Processing subsystem is shown in Figure 97. Event processing 
establishes a ranking of input events so that higher priority events supersede lower priority 
events. 


CD ►! chg | ►CD) 

ls_Pilot_Flying_Side When_Pilot_Fllying_Transfer_Seen 



Figure 97 - Event Processing 

Blocks such as SYNC _Switch_Pressed_Seen instantiate the Seen logic shown in Figure 97, which 
outputs Seen as true if its Input signal is true while the Inhibitln signal is false. This block also 
generates an Inhibit Out signal when either the Inhibit ln input or the Seen output is true. 
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AND 


Figure 98 - Seen Logic 

These blocks can be cascaded as shown in Figure 97 to inhibit generation of low priority events 
when a higher priority event occurs at the same time. In this way, simultaneous input events are 
resolved in favor of the more important events, providing a mechanism to ensure that only one 
lateral and one vertical mode becomes active on each step. 

It is not necessary to preempt all simultaneous events. For example, the HDG Switch Pressed 
event can occur simultaneously with the VS_Switch_Pressed event without conflict. For this 
reason, the prioritization of events is organized in a lattice that allows some simultaneous events. 
This helps to ensure that as few input events as possible are inhibited. Identifying which events 
can safely occur simultaneously is done through model checking. 

Most of the blocks are guarded by a rising edge detector, which is true for the one step on which 
the input transitions from false to true. These blocks generate signals that correspond to events, 
which can only be true for one step. However, some blocks, such as 
LAPPR_Capture_Cond_Met_Seen, are not preceded by rising edge detectors. These blocks 
establish a priority on input conditions, which can be true for several steps. Input conditions are 
given a lower priority than input events. This allows the mode logic to respond to a high priority 
input event and still respond to an input condition (that will probably still be true) on the 
subsequent step. 

Also, note that the When_Pilot_Flying_Transfer_Seen event is set true whenever the 
Is_Pilot_Flying input (indicating if this is the pilot flying side of the aircraft) changes value. This 
event does not conflict with any other inputs or conditions and is neither inhibited nor inhibits 
the other outputs of Event Processing. 
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The advantage of this approach is that it isolates the handling of conflicting input events into one 
place where it is easier to reason about their priority. While discarding some events might seem 
unsafe, a simple thought exercise shows that it is safe and preferable to discard the lower priority 
event than it is to try to process both events. Consider the situation in the FGS in which the lower 
priority event occurs immediately after the higher priority event. In that situation, the lower 
priority event effectively overrides the higher priority event. Now consider the situation in which 
the higher priority event occurs immediately after the lower priority event. In that situation, the 
higher priority event effectively overrides the lower priority event. Both sequences can happen in 
the FGS and both result in safe flight. So discarding the lower priority event is acceptable since it 
corresponds to the situation in which the lower priority event occurs immediately before the 
higher priority event. Allowing some events to occur simultaneously because they do not 
conflict with each other is a modest advantage made feasible through fonnal verification. 

4.3. 2. 2 Alternatives to Event Prioritization 

There are other approaches to resolving conflicting simultaneous events. One approach is to 
resolve the conflicts by adding constraints in the tables for mode activation that directly consider 
all possible combinations of inputs. However, this can quickly become overwhelming and 
obscures the most important cases when there aren’t simultaneous inputs. It also unnecessarily 
entangles the logic of the different modes. 

Another approach is to add an Active state machine that keeps track of which mode is currently 
active and use it to coordinate the individual mode machines. While appealing on the surface, it 
has several disadvantages. First, unlike the individual mode machines, it does not represent an 
abstraction of the underlying system state; its purpose is to enforce the constraint that only one 
lateral mode and one vertical mode can be active at a time. An indication of this is the fact that 
there must be a transition from every active mode to every other active mode, since any mode 
can become active at any time. However, the more important issue is that it separates the logic 
for making a mode active from the logic for anning and clearing the modes. This leads to a 
model of the mode logic that is distributed across several state machines and is difficult to 
understand. 

The approach taken here is to represent each mode as a small, relatively independent, state 
machine that represents an abstraction of the underlying flight control law. Rather than building 
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complex structures to enforce constraints required by the physical aircraft, we use fonnal 
analysis to ensure those constraints are met. 

4.4 Formal Verification of the Mode Logic 

This section discusses how model checking can be used to formally verify that the Mode Logic 
model meets is requirements. Since model checking is so highly automated, more of the 
emphasis shifts to writing good properties than in theorem proving. In Section 4.4.1, we discuss 
informal heuristics for writing good properties. In Section 4.4.2 we use these heuristics to 
develop formal properties for the mode logic and verify them using the Kind SMT-based model 
checker. In Section 4.4.3 we discuss verifying a subset of these properties using MATLAB 
Design Verifier. 

4.4.1 Heuristics for Writing Formal Properties 

Writing good fonnal properties shares many similarities with writing good requirements and is 
as much art as science. Fortunately, most organizations tend to build variations of the same 
systems and will develop libraries of good properties over time. However, writing that first set of 
properties can be challenging. Fonnal properties do have the advantage over requirements that 
they can be mathematically checked against a model of the system and even a single property 
can find many enors. In many ways, it is more important to get started than it is to write the ideal 
set of properties. This section describes several strategies, heuristics, and rules of thumb for 
writing good formal properties. While certainly incomplete and infonnal, many of these were 
followed in developing the formal properties for the mode logic discussed in the next section. 

One of best sources of formal properties is often found in the safety-related 6 requirements for the 
system. Not only are these requirements inherently important, but their implementation typically 
touches on several parts of the system. Properties that cut across an entire system in this way 
often find the most errors. For example, in the mode logic, the properties that found the most 
errors were those that checked that at least one lateral and vertical mode was active and that at 
most one lateral and vertical mode was active. These properties depended on the correct 
interaction of all the modes and cut across the entire model. 


6 Here “safety-related requirements” are those can affect the safe operation of the aircraft as used in DO-178C rather 
than the formal methods notion of a predicate over a finite number of successive states. 


136 



If the system developers or domain experts are available, another good strategy is to simply ask 
them what things they are the most worried about in the system. Refining their concerns into a 
set of formal properties often requires an ongoing dialogue 7 , but their intuition and knowledge of 
the system can be invaluable. 

Another excellent source of fonnal properties is the system or software requirements. Informal 
requirements can take on many different forms, from text to block diagrams to state-machines to 
use cases to pseudo-code, but their intent is always to describe what the system should do 
without specifying how it should do it. Often, an infonnal requirement actually encompasses 
several properties. A strategy that we have used successfully is to transcribe the infonnal 
requirement into one or more textual statements and then writing a fonnal property for each 
textual statement. 

User manuals can also be an excellent source of fonnal properties. Often, user manuals are 
written with less design infonnation than the system requirements. Most of the requirements for 
the mode logic were originally developed from user manuals describing the system for pilots. 

Once the above sources of properties have been exhausted, another option is to carefully review 
the model itself looking for anything that is not checked by a property. Often, this will identify 
requirements (and hence properties) that have been completely omitted. Surprisingly, even 
writing properties directly from the model itself will often expose errors in understanding the 
semantics of the model and should not be ruled out as a strategy. 

Another heuristic that can be helpful in developing properties is to consider each input and try to 
identify all the ways that changing that input can affect one or more outputs and then write 
properties describing each such change. This provides a systematic way of breaking the problem 
down into several small problems and identifying properties. Ideally, the behavior of the system 
expressed in the requirement is gleaned from requirements or user manuals. 

A final guideline concerns the process of writing properties and their verification. When a 
property is found to be false, this only means that there is a discrepancy between the fonnal 
property and the model. As often as not, such discrepancies expose errors in the property rather 


7 

For example, when asked this question one developer replied simply “whether it’s right.’’ Further discussion led to 
the development of several important safety-related properties. 
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than in the model, and these take the form of missing assumptions. For example, the original 
requirement may be written as “the system shall arm for vertical approach mode when the APPR 
button is pressed” but fonnal verification reveals that this is true unless an overspeed condition 
exists. In this situation, it is probably the fonnal property, not the model, which needs to be 
conected. Since many requirements will share the same undocumented assumptions, it is 
generally best to check properties incrementally as they are developed rather than developing all 
the properties and then checking them. In this way, insights gained from verifying the first 
properties can be incorporated into the development of later properties. 

4.4.2 Verification of the Mode Logic Using the Kind Model Checker 

This section describes how the Kind Model Checker can be used to formally verify that the 
MATLAB Simulink/Stateflow model described in Section 4.2 meets its requirements. To do this, 
the model must be translated into the Lustre language accepted by the Kind model checker and 
the requirements stated formally in Lustre. The translation into Lustre has been performed using 
the Rockwell Collins Fonnal Verification Framework. The resulting file is provided along with 
this report. Section 4.4.2. 1 describes how the safety-related requirements and functional 
requirements are stated formally in the Lustre language. Section 4. 4.2. 2 discusses the process of 
understanding the counterexamples produced from three false properties and conecting the 
Mode Logic model. 

4.4.2. 1 Writing Properties for the Kind Model Checker 

There are 118 properties that have been formally verified for the mode logic. These are listed in 
Appendix B - Mode Logic Properties. The reader may wish to refer to that appendix while 
reading this section. We specify properties in Lustre by defining a unique Boolean variable for 
each requirement and assigning to this variable the formal specification of the requirement. For 
example, the requirement that at least one lateral mode shall always be active is specified as 


-- At least one lateral mode shall always be active 
-- when the FD is displayed or the AP is engaged. 


At Least_One_Lateral_Mode_Active = 

ROLL_Active or HDG_Active or NAV_Active or LAPPR_Active or LGA_Active; 
check At_Least_One_Lateral_Mode_Active ; 

Figure 99 - At Least One Lateral Mode Active (Lustre) 
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We have chosen to use descriptive names such as At_Least_One_Lateral_Mode_Active for the 
Boolean values assigned to requirements. Any unique valid Lustre name, for example, R0015a, 
would also be acceptable. We will also follow the convention of embedding the informal, textual 
statement of the requirement in Lustre comments (lines starting with “ — “) immediately before 
the formal statement of the requirement. The requirement is then formally specified by assigning 
a predicate defining the requirement to the Boolean variable. In the case of Figure 99 this is just 
a Boolean expression stating that at least one of the system outputs specifying the active status of 
the lateral modes must be true. Finally, the “check” statement instructs the Kind model checker 
to attempt to prove the property is always true for all possible combination of inputs and states. 

Note that we have actually verified a stronger requirement than the one stated in the informal 
textual requirement which requires that a lateral mode must be active when the FD is displayed 
or the AP is engaged. Its proof demonstrates at least one lateral mode is always active, not just 
when the FD is displayed or the AP is engaged. It is always acceptable to prove a stronger 
property than is actually required, though we may wish to keep track of the original requirement 
in case changes to the model invalidate the stronger property. If this stronger property was not 
true of our model, the weaker actual property could be stated using an implication as shown in 
Figure 100. 


-- At least one lateral mode shall always be active 
-- when the FD is displayed or the AP is engaged. 


At Least_One_Lateral_Mode_Active = 

FD__On or I s_AP_Engaged => 

ROLL_Active or HDG_Active or NAV_Active or LAPPR_Active or LGA_Active; 
check At_Least_One_Lateral_Mode_Act ive ; 

Figure 100 - Weaker Version of at Least One Lateral Mode Active (Lustre) 

The requirement that at least one lateral mode is always active when the FD is on or the AP is 
engaged is an example of a safety-related software requirement that traces to a system level 
safety requirement that the FGS shall provide valid guidance when the FD is on or the AP is 
engaged. As discussed in 4.4.1, safety-related requirements are excellent candidates for fonnal 
verification. This is partly because of their explicit relationship to system safety, but it is also due 
to the inherent difficulty of testing them. Safety-related requirements are often of the form “bad 
things shall never happen” or conversely, “good things shall always happen.” Such requirements 
are difficult to test since testing can demonstrate their truth only for states and inputs actually 


139 



tested. In contrast, formal verification proves them to be true for all possible combinations of 
inputs and system states. Safety-related requirements are also excellent properties for finding 
design errors since the entire system often contributes to maintaining safety-related requirements 
and an error anywhere in the system will often falsify the requirement. 

Another safety-related requirement is the requirement that no more than one lateral mode can 
ever be active at the same time. This is important since having two lateral flight control laws 
active at the same time would generate conflicting guidance commands to the FD and the AP. 
This requirement is formally stated in Figure 101. 


-- At most one lateral mode shall be active 
-- when the FD is displayed or the AP is engaged. 


At_Most_One_Lateral_Mode_Active = 

(ROLL_Active => 

not ( HDG_Active or NAV_Active or LAPPR__Active or LGA_Active) ) and 

(HDG_Active => 

not (ROLL_Active or NAV_Active or LAPPR_Active or LGA_Active) ) and 

(NAV_Active => 

not (ROLL^Active or HDG_Active or LAPPR_Active or LGA_Active) ) and 

(LAPPR_Active => 

not (ROLL_Active or HDG_Active or NAV_Active or LGA_Active) ) and 

(LGA_Active => 

not (ROLL_Active or HDG_Active or NAV_Active or LAPPR_Active ) ) ; 

check At_Most_One_Lateral_Mode_Active ; 

Figure 101 - At Most One Lateral Mode Active (Lustre) 

The requirements for at least one and at most one lateral mode active could be combined into a 
single requirement that exactly one lateral mode shall be active. We have chosen to state them as 
separate requirements as a matter of preference. In similar fashion, there are requirements that at 
least one vertical mode shall be active and at most one vertical mode shall be active. 

Another safety-related requirement is that VAPPR (vertical approach) mode shall be active only 
if LAPPR (lateral approach) mode is active. This is important since the aircraft should not be 
making a vertical descent to land when it isn’t aligned with the runway. It turns out to be 
difficult to deactivate VAPPR mode on the exact step in which LAPPR mode is deactivated, but 
easy to deactivate VAPPR mode on the next step after LAPPR is deactivated. Since a delay of 
one step is insignificant given the inertia of the aircraft, this requirement can be relaxed to allow 
a one-step delay in clearing VAPPR mode when LAPPR mode is deactivated. This can be 
formally stated as “if VAPPR mode is active on two successive steps, LAPPR mode must be 
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active on the first step.” Since this is true for any two successive steps, it is equivalent to 
requiring that LAPPR must be active when VAPPR is active except on the last step in which 
LAPPR is active. This is shown in Figure 102 using the Lustre “pre” operator which returns the 
value of a variable on the previous step. 

-- VAPPR mode shall be active only if LAPPR mode is active (except on the last step) . 

VAPPR_Active_Implies_LAPPR_Active = 

(pre VAPPR_Active and VAPPR_Active) => pre LAPPR_Active ; 

check VAPPR_Active_Implies_LAPPR_Active ; 

Figure 102 - VAPPR Active Only If LAPPR Active (Lustre) 

Of course, the weakening of the original requirement to accommodate the design decision 
allowing a one-step delay needs to be fed back into the system safety process for review as 
specified in DO-178B/C to ensure that it does not violate the system safety requirements. 

Another safety-related requirement is that LGA (lateral go around) mode shall be active if and 
only if VGA (vertical go around) mode is active. These modes are active only during takeoff or 
during a go around following an aborted landing. The LGA flight control law maintains a fixed 
heading while the VGA flight control law maintains a fixed pitch and both modes should be 
active at the same time. Similar to the requirement that VAPPR mode active implies LAPPR 
mode active, this requirement is much simpler to implement if it can be relaxed for one step. For 
this reason, the requirement is specified as two implications as shown in Figure 103. 

-- VGA mode shall be active if LGA mode is active (except for one step) . 

LGA_Active_Implies_VGA_Active = 

(pre LGA_Active and LGA_Active) => pre VGA_Active; 

check LGA_Active_Implies_VGA_Active ; 

-- LGA mode shall be active if VGA mode is active (except for one step) . 

VGA_Active_Implies_LGA_Active = 

pre VGA_Active and VGA_Active => pre LGA_Active; 

check VGA_Active_Implies_LGA_Active ; 

Figure 1 03 - LGA Active If and Only If VGA Active (Lustre) 

Another safety-related requirement is that when an overspeed condition occurs, either FLC, 
ALT, or ALTSEL mode shall be active. The normal response of the FGS to an overspeed 
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condition is to enter FLC mode to pitch the aircraft up to reduce speed. However, to avoid 
moving outside of the aircraft’s assigned flight level, the pilot may select either ALT mode to 
hold the aircraft at its current altitude or the aircraft may activate ALTSEL mode by capturing 
and tracking the preselected altitude. However, trying to prove this requirements reveals that 
there are several ways in which either ALT or ALTSEL mode can be deactivated (e.g., 
deselection by the pilot, rotating the VS Pitch Wheel, or a pilot flying transfer) causing the 
aircraft to enter basic PITCH mode in which it holds the current pitch angle. However, we can 
prove that FLC, ALT, ALTSEL, or PITCH mode must be active when an overspeed condition 
exists as shown in Figure 104. 

— FLC, ALT, ALTSEL, or PITCH mode shall be active 
-- while an overspeed condition exists. 

Overspeed_Implies_FLC_ALT_ALTSEL_PITCH = 

Overspeed => FLC_Active or ALT^Active or ALTSEL Active or PITCH_Active; 

check Overspeed_Implies_FLC_ALT_ALTSEL_PITCH; 

Figure 104 - Overspeed Implies FLC, ALT, ALTSEL, or PITCH Active (Lustre) 

Once in PITCH mode, FLC will immediately be selected due to the overspeed condition, so 
PITCH mode can be active for only one step while an overspeed condition exists. We confirm 
this by proving the property shown in Figure 105 that if PITCH is active in one step and an 
overspeed condition exists in the next step, the system shall exit PITCH mode. 

-- PITCH mode shall be active for only one step while an overspeed condition exists. 

Overspeed_and_PITCH_Transitory = true -> 

pre PITCH_Active and Overspeed => not PITCH_Active; 

check Overspeed_and_PITCH_Transitory ; 

Figure 105 - Overspeed and PITCH Transitory (Lustre) 

The -> (followed by) operator of Lustre (not to be confused with the => implies operator) is used 
in Figure 105 to exclude the initial system state from the proof. The -> operator replaces the 
value of the Boolean predicate in the first step with the value true (its left hand operand) and uses 
the value of the predicate (its right hand operand) for all subsequent steps. This is necessary 
since as it is possible for the Overspeed input to be true in the initial step before the system has 
had time to respond to it. The -> operator is a convenient way to exclude the initial system state 
from proofs in which the validity of the property in the initial step does not matter. 
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When combined with the proof of Figure 104 this proves that FLC, ALT, or ALTSEL mode 
must be active during an overspeed condition except for one transitory step during which PITCH 
mode can be active. As before, these requirement changes must be fed back into the system 
safety process for review. 

As discussed in Section 4.4.1, another useful source of properties is the functional requirements 
for the mode logic or the user’s manual. For example, HDG is simple lateral mode in which the 
aircraft acquires and tracks a heading reference (i.e. a compass direction). Both the system 
requirements and the user’s manual for the FGS state that this mode should be selected whenever 
the pilot presses the HDG button on the FCP if HDG mode is not already selected. This is 
formally stated as shown in Figure 106. 

-- HDG mode shall be selected if the HDG switch is pressed while HDG mode is cleared. 

HDG_Switch_Pressed_Selects_HDG = 

not pre HDG_Selected and RISING (HDG_Switch) 

and No_Higher_Event Than_HDG_Switch_Pressed => HDG_Selected; 
check H DG_S wit ch_Pr esse d_Selects_HDG; 

Figure 106 - HDG Switch Pressed Selects HDG (Lustre) 

Formally stating the requirement of Figure 106 requires the introduction of two auxiliary 
definitions in Lustre. The first of these, the function RISING, is quite simple. Its definition is 
shown in Figure 107. 

-- RISING - returns true when signal s changes from false to true 

node RISING (s : bool) returns (p : bool); 
let 

p = false -> (not pre s and s) ; 
tel; 

Figure 107 - Definition of RISING (Lustre) 

RISING takes a single Boolean valued input and returns true if its value has changed from false 
to true. Note that its value in the initial step is always false. The function RISING must be used in 
the fonnal statement of Figure 106 since the mode logic only responds a rising value of the input 
HDG Switch as shown in the Event Prioitization logic of Figure 97. 

The second auxiliary definition, No_Higher_Event_Than_HDG_Switch_Pressed, is more 
complicated. Recall that the Event Prioritization logic described in Section 4.3.2. 1 masks some 
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input events when a higher priority event occurs at the same time. Since the input HDGSwitch 
refers to the system level input rather than the possibly masked value 
HDG Switch Pressed Seen passed into the Flight_Modes specification (Section 4.3.1), formally 
specifying the conditions under which HDG mode is selected must incorporate the behavior in 
the event prioritization logic. 

One way to do this would be to use the internal value HDGSwitchPressedSeen computed in 
the model itself to formally state the requirement. A practical difficulty in doing this is that the 
intermediate value’s name in the Lustre specification may be quite different from the name used 
by the Simulink designer due to the translation process. In fact, the intermediate value may even 
have been optimized away during translation. However, if both of these obstacles were 
overcome, the requirement of Figure 106 could be restated as shown in Figure 108. 

-- HDG mode shall be selected if the HDG switch is pressed while HDG mode is cleared. 
HDG_Switch_Pressed_Selects_HDG = 

not pre HDG_Selected and HDG_Switch_Pressed__Seen => HDG_Selected; 
check H DG_S wit ch_Pr esse d_Selects_HDG; 

Figure 108 - HDG Switch Pressed Selects HDG Using Internal Variables (Lustre) 

Despite its intuitive appeal, there is a more insidious danger in using internal values to specify 
properties. The problem is that the validity of the proof now depends on the correctness of the 
model itself. For example, imagine that the portion of the model that computes 
HDG Switch Pressed Seen is incorrect and always returns the value false. The property is then 
trivially true since false => p is always true for any predicate p. The effect would be that an error 
in the portion of the model defining HDG Switch Pressed Seen could mislead us into believing 
the property of Figure 108 was true when it was actually false. 

One solution to this problem would be to prove the correctness of the internal variable with its 
own set of properties. Another solution, and the one that we have used here, is to only use input 
and output variables (i.e. no internal variables) in our properties. However, restricting the 
variables in properties to only system input and output variables leads to verbose properties 
unless we first introduce auxiliary definitions that independently specify portions of the model. 
The function RISING is one example of such an auxiliary definition. Another is the Lustre 
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variable No_Higher_Event_Than_Heading_Switch_Pressed. Its definition is shown in Figure 
109. 

No_Higher_Event Than_HDG_Switch_Pressed = 

(not RISING (APPR_Switch) and No_Higher_Event_Than_APPR_Switch_Pressed) ; 

Figure 109 - No Higher Event Than HDG Switch Pressed (Lustre) 

The purpose of this variable is to independently specify the event prioritization logic relevant to 
the HDG switch. It is set to the value true if the next higher priority event, the pressing of the 
APPR switch, does not occur and no even higher priority event than the pressing of the APPR 
switch occurs. Of course, the Lustre variable No_Higher_Event_Than_APPR_Switch_Pressed 
must also be defined, but the resulting collection of recursive definitions nicely captures the 
event prioritization logic in a form that supports succinct specification of mode logic properties. 
For example, fonnalizing the requirement that HDG mode should be selected if the HDG switch 
is pressed while HDG mode is cleared can be written as shown in Figure 106. 

Since HDG mode is a non-arming mode, to complete the verification of its functional behavior 
we need to specify all ways in which HDG mode can be selected and all ways in which HDG 
mode can be cleared. HDG mode can only be selected by the pilot pressing the HDG switch, but 
there are three ways in which HDG mode can be cleared. These are shown in Figure 110. 

-- HDG mode shall be cleared if the HDG switch is pressed while HDG mode is selected. 

HDG_Switch_Pressed_Clears_HDG = 

pre HDG_Selected and RISING (HDG_Switch) 

and No_Higher_Event_Than_HDG_Switch_Pressed => not HDG_Selected; 
check HDG_Switch Pressed_Clears_HDG; 

-- HDG mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_HDG = 

pre HDG_Selected and CHANGED ( Pilot Flying_Side) => not HDG_Selected; 
check Pilot_Flying_Transf er_Clears_HDG; 

-- HDG mode shall be cleared when the mode annunciations are turned off. 

Modes_Of f_Clears_HDG = 

pre HDG_Selected and not Modes_On => not HDG_Selected; 
check Modes_Of f_Clears_HDG; 

Figure 110 - Functional Requirements for Clearing HDG Mode (Lustre) 
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The functional requirements for arming modes such as NAV, LAPPR, ALTSEL, and VAPPR 
must include properties describing how an armed mode becomes active. Our first attempt at 
formalizing a property specifying how NAV mode can become active is shown in Figure 111. 


-- NAV mode shall become active if the NAV capture condition is met 
-- while NAV mode is armed. 


NAV_Active_When_Capture_Cond_Met = true -> 
pre NAV_Selected and not pre NAV_Active 
and NAV_Capture_Cond_Met 

and No_Higher_Event_Than_NAV_Capture_Cond_Met => NAV_Active; 


check NAV_Active_When_Capture_Cond_Met ; 

Figure 111 - Initial Functional Requirements for Activating NAV Mode (Lustre) 

This property specifies that NAV mode is anned by stating that it is selected but not active in the 
previous step. There is also no need to look for the rising edge of NAV_Capture_Cond_Met since 
the mode logic transitions from anned to active whenever the NAV capture condition is true, not 
just on its rising edge. However, attempting to prove this property identifies several conditions 
under which it is not true. The correct property is shown in Figure 1 12. 


-- NAV mode shall become active if the NAV capture condition is met 
-- while NAV mode is armed. 


NAV_Active_When_Capture_Cond_Met = true -> 
pre NAV_Selected and not pre NAV_Active 
and NAV_Capture_Cond_Met 
and not Selected_NAV_Source_Changed 
and not Selected_NAV_Frequency_Changed 
and not CHANGED (Pilot Flying Side) 
and Modes_On 

and No_Higher_Event_Than_NAV_Capture_Cond_Met => NAV_Active; 


check NAV_Active_When_Capture_Cond_Met ; 

Figure 112 - Correct Functional Requirements for Activating NAV Mode (Lustre) 

For most arming modes it is possible for the mode to be either activated or cleared while armed, 
depending on external events. NAV mode will be cleared if the selected navigation source is 
changed (e.g. selecting a different type of navigation beacon), the frequency is changed, the 
Transfer switch is pressed (causing a change in the pilot flying side) or the mode annunciations 
are turned off. All of these conditions must be incorporated into the antecedent of the property. 

This illustrates one of the most important benefits of fonnal specification - it forces a precise 
enumeration of the exceptions to the normal case. Note that we have not gone back and revised 
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the textual in formal specification of the requirement to include these exceptions. Instead, we 
have chosen to leave the informal specification the way it was originally written since this 
captures the requirement’s original intent. The exceptions are then documented in the fonnal 
specification. 

4.4.2.2 Debugging False Properties in Kind 

One of the most important benefits of formal verification is its ability to find errors that 
traditional verification approaches such as reviews or testing would miss. For example, sixteen 
errors were found when verifying the MATLAB Simulink/Stateflow model of the mode logic 
using the Kind model checker (see Appendix C). Even though this example had been specified 
previously in RSML' e [4] and formally verified using the NuSMV model checker, the process of 
rewriting it in Simulink/Stateflow was sufficient to introduce new errors. This section discusses 
a few of the errors listed in Appendix C and describes the process of understanding why a 
property is false and correcting the problem. 

4.4.2.2.1 VGA Clear Error 

Our first example is a simple naming error that was found by the Kind model checker in a few 
seconds. While this error would probably have been found through testing, it was simpler and 
faster to find it through model checking. It is also a good first example because of its simplicity. 
The error was made in the specification of the VGA mode and is shown in Figure 113. 


VGA 



Figure 1 13 - VGA Clear Error 

The output variable LGA_Active, rather than VGA_Active, was being set to false on exiting 
ACTIVE mode. This error was detected while trying to prove that at least one lateral mode is 
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always active (Figure 99). The counterexample produced by the Kind model checker is shown in 
Figure 1 14. 



Step 1 

Step 2 

Step 3 

Input Siqnals 




ALTSEL Capture Cond Met 

false 

false 

false 

ALTSEL Target Changed 

false 

false 

false 

ALTSEL Track_Cond Met 

false 

false 

false 

ALT Switch 

false 

false 

false 

APPR Switch 

false 

false 

false 

FD Switch 

true 

false 

true 

FLC Switch 

false 

false 

false 

GA Switch 

false 

true 

false 

FIDG Switch 

false 

true 

false 

Is AP Engaged 

true 

false 

false 

Is Offside VAPPR Active 

false 

false 

false 

Is Offside VGA Active 

false 

false 

true 

LAPPR Capture Cond Met 

false 

false 

false 

NAV Capture Cond Met 

false 

false 

false 

NAV Switch 

true 

false 

false 

Offside FD On 

false 

false 

false 

Overspeed 

false 

false 

false 

Pilot Flying Side 

true 

false 

false 

SYNC Switch 

true 

true 

false 

Selected NAV Frequency Changed 

false 

false 

false 

Selected NAV Source Changed 

false 

false 

false 

VAPPR Capture Cond Met 

false 

false 

false 

VS Pitch Wheel_Rotated 

false 

false 

true 

VS Switch 

false 

false 

false 





Output Siqnals 




FIDG Active 

false 

false 

false 

LAPPR Active 

false 

false 

false 

LGA Active 

false 

true 

false 

NAV Active 

false 

false 

false 

ROLL Active 

true 

false 

false 


Figure 114 -Counterexample for Clearing VGA Error 

The counterexample is three steps long with the values of the relevant inputs and outputs shown 
for each step (Kind does not generate values for inputs and outputs that do not affect the 
property). Values that have not changed from the previous step are shown in grey text. The most 
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significant values have had their enclosing box shaded in grey by the authors to help in 
understanding the counterexample. 

In the initial step ROLL mode is active as expected. In the second step, the GA switch is pressed, 
activating LGA mode. This also activates VGA mode, though VGA_Active is not included in the 
counterexample since its value is not directly relevant to the property. In step 3, the VS Pitch 
Wheel is rotated, which clears VGA mode. This does not actually clear LGA mode in step 3 
(though LGA mode would be cleared in step 4), but due to the naming error, the output variable 
LGA_Active is incorrectly set to false, making it appear that LGA mode has been cleared. 

This example illustrates several important points about model checking. First, the model checker 
will produce a counterexample if it can invalidate a property, but it may not be the best 
counterexample for human comprehension. In understanding a counterexample, changes in 
values are often important clues (for example the GA switch being pressed in step 2), but the 
model checker may also change values that have no impact on outputs. For example, the HDG 
switch is pressed in step 2, but this is not relevant since it is masked due to event prioritization by 
the pressing of the GA switch. Finally, though not demonstrated here, if the model can be 
simulated it may be even more helpful to step through the simulation using the input values 
provided by the counterexample. 

4A.2.2.2 FLC Select Error 

Our second example is a much more subtle design error that probably would not have been found 
through testing. It also would have allowed two vertical modes to be active while an overspeed 
condition existed. The error was made in the specification of the selection logic for FLC mode 
and is shown in Table 48. 


Table 48 - FLC Select Error 


Condition 

1 

2 

3 

FLC Switch Pressed 

T 

- 

- 

VAPPR Active 

F 

- 

- 

Overspeed 

- 

T 

- 

ALT Active 

- 

F 

- 

ALTSEL Active 

- 

F 

- 

TRUE 

TRUE 

FALSE 
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The error was detected while trying to prove that no more than one vertical mode is ever active. 
The counterexample produced by the Kind model checker is shown in Figure 115. 



Step 1 

Step 2 

Input Siqnals 



ALTSEL Capture Cond Met 

false 

false 

ALTSEL Target Changed 

false 

false 

ALTSEL Track_Cond Met 

false 

false 

ALT Switch 

false 

true 

APPR Switch 

false 

false 

FD Switch 

false 

true 

FLC Switch 

false 

true 

GA Switch 

true 

false 

FIDG Switch 

false 

false 

Is AP Engaged 

false 

true 

Is Offside VAPPR Active 

false 

false 

Is Offside VGA Active 

false 

false 

LAPPR Capture Cond Met 

false 

false 

NAV Capture Cond Met 

false 

false 

NAV Switch 

false 

false 

Offside FD On 

false 

false 

Overspeed 

false 

true 

Pilot Flying Side 

true 

true 

SYNC Switch 

true 

false 

Selected NAV Frequency Changed 

false 

false 

Selected NAV Source Changed 

false 

false 

VAPPR Capture Cond Met 

false 

false 

VS Pitch Wheel Rotated 

false 

true 

VS Switch 

false 

true 




Output Siqnals 



ALTSEL Active 

false 

false 

ALT Active 

false 

true 

FLC Active 

false 

true 

PITCH Active 

true 

false 

VAPPR Active 

false 

false 

VGA Active 

false 

false 

VSActive 

false 

false 


Figure 115 - Counterexample for FLC Select Error 

In the initial step PITCH mode is active as expected. In the second step, the ALT switch is 
pressed, activating ALT mode. However, an overspeed condition also occurs in the second step, 
activating FLC mode. This occurred because of a design decision to never mask an overspeed 
condition in the Event Prioritization logic of Section 4.3.2. 1. 
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In this situation, precedence should be given to the pilot’s selection of ALT mode to hold the 
aircraft at the current altitude. To enforce this, the FLC selection logic of Table 48 must be 
modified to return false if ALT will become active in this step and not just if it is already active. 
A similar change must be made if ALTSEL will become active in this step. The correct logic for 
FLC Select is shown in Table 29 on page 123. 

It is worth noting that this error would have been very difficult to detect through testing since it 
depends on two events (the pilot pressing the ALT switch and the start of an overspeed 
condition) on the exact same step. It also would have been very difficult to find through 
inspection since very few reviewers would catch a corner condition such as this. The error also 
has an unknown impact on safety since it’s not clear what the behavior of the aircraft would be 
with two flight control laws active at the same time. 

4A.2.2.3 ALTSEL Select Error 

The last error illustrates how execution order can affect the behavior of a Stateflow model in 
subtle ways. As discussed in Section 4. 3. 1.4.4, ALTSEL mode is to be cleared when ALT, 
VAPPR or VGA are active and selected when none of them are active. This requirement is 
captured in the property of Figure 1 16 below. 

-- If the mode annunciations are on, ALTSEL mode shall be selected if 
-- none of ALT, VAPPR, or VGA mode are active. 

ALTSEL_Selected_If JNIot_ALT_VAPPR_VGA_Active = true -> 

Modes_On and not (ALT_Active or VAPPR_Active or VGA_Active) => ALTSEL_Selected; 

check ALTSEL_Selected_If_Not_ALT_VAPPR_VGA_Active; 

Figure 1 16 - ALTSEL Select Error (Lustre) 

However, the Kind model checker was able to falsify this property in a few seconds, producing 
the counterexample shown in Figure 117. 
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Input Siqnals 




ALTSEL Capture Cond Met 

true 

false 

false 

ALTSEL_Target_Changed 

false 

false 

true 

ALTSEL_T rack_Cond_Met 

false 

false 

false 

ALT_Switch 

false 

false 

true 

APPRSwitch 

false 

false 

true 

FD Switch 

false 

false 

true 

FLCSwitch 

false 

false 

true 

GASwitch 

false 

true 

false 

FIDGSwitch 

false 

false 

true 

IsAPEngaged 

false 

false 

false 

IsOffsideVAPPRActive 

false 

false 

false 

IsOffsideVGAActive 

false 

false 

true 

LAPPRCaptureCondMet 

true 

false 

false 

NAV_Capture_Cond_Met 

false 

false 

false 

NAVSwitch 

false 

false 

true 

OffsideFDOn 

true 

false 

false 

Overspeed 

false 

false 

false 

PilotFlyingSide 

false 

false 

false 

SYNC Switch 

false 

false 

true 

SelectedNAVFrequencyChanged 

false 

false 

false 
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Figure 117- Counterexample for ALTSEL Select Error 

In step 1 ALTSEL mode is selected with ALT, VAPPR, and VGA cleared as expected. In step 2, 
the GA Switch is pressed, causing VGA mode to become active. However, ALTSEL mode does 
not clear as expected. In step 3, the SYNC switch is pressed, clearing VGA mode. However, 
ALTSEL mode now clears. 

This unexpected behavior occurred because in the original model, ALTSEL mode was assigned 
to execute immediately after ALT mode and before VAPPR and VGA mode. As a result, the 
ALTSEL selection logic of Table 35 on page 127 referred to the value of ALT _Active after ALT 
mode had executed and the values of VAPPR_Active and VGA_Active before VAPPR and VGA 
mode had executed. As a result, there was a one-step delay in the reaction of ALTSEL mode to 
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changes in VAPPR and VGA mode while changes in ALT mode were processed in the same 
step. 

While this was not a particularly serious error, it does violate the original requirement. It could 
lead to considerable confusion during debugging, and it would also be very difficult to find using 
testing or reviews. 

Fortunately, this error was easily fixed by assigning ALTSEL mode to execute after ALT, 
VAPPR, and VGA modes but before PITCH mode. To make this clear, the position of ALTSEL 
mode was changed so it was positioned immediately before PITCH mode. 

4.4.3 Verification of the Mode Logic Using MATLAB Design Verifier 

It is also possible to formally state and verify properties using MATLAB Design Verifier. 
Properties can be specified either graphically as Simulink/Stateflow models or textually as 
MATLAB function blocks. For example, the graphical specification of the requirement that at 
least one lateral mode shall be active is shown in Figure 118. 


At_Least_One_Lateral_Mode_Active: 

At least one lateral mode shall be active. 



Figure 118 - At Least One Lateral Mode Active (Design Verifier) 

This Simulink block simply computes the OR of the output signals for each active mode. The 
circular “P” icon is a proof objective block from the Design Verifier library. When Design 
Verifier is invoked on the model, it will attempt to prove that its value is always true (or 
whatever value has been specified in its dialog box). 
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The specification of the slightly more complex requirement that NAV mode shall become active 
when the NAV capture condition is met is shown Figure 119. 


NAV_Active_When_Capture_Cond_Met: 

NAV mode shall become active if the NAV capture condition is met while NAV mode is armed. 



Figure 119 - NAV Active When Capture Cond Met (Design Verifier) 

The implication (A ==> B) block used in Figure 1 19 is also part of the Design Verifier library. It 
returns true if the antecedent A is false or the consequent B is true. Note this property is true only 
when the selected NAV source and frequency are not being changed and a pilot flying transfer is 
not occurring and the mode annunciations are on and no higher priority event is masking the 
capture condition. 

To illustrate the textual specification of properties, the requirement that at least one vertical 
mode is active is specified as a MATLAB function block in Figure 120. 

function At_Least_One_Vertical_Mode_Active (PITCH_Active, VS_Active, FLC_Active, 

ALT_Active, ALTSEL_Active, VAPPR_Active, VGA_Active) 

% At least one vertical mode shall be active. 

P = ( PITCH_Active I I FLC_Active I I ALT_Active I I 
ALTSEL_Active I I VAPPR_Active I I VGA_Active) ; 

sldv. prove (P) ; 

Figure 120 - At Least One Vertical Mode Active (Design Verifier) 
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The command sldv.prove(P) behaves similar to the Proof Objective of Figure 118 and instructs 
Design Verifier to attempt to prove that P is true for all combinations of inputs and outputs. 

For convenience, we group both the graphical and textual properties into one or more subsystem 
blocks as shown in Figure 121. 


o 


Outputs 


< 


[Outputs] 



Figure 121 - Properties Subsystem (Design Verifier) 

This block has bus input signal (Inputs) that contains all the inputs to the Mode Logic and a bus 
output signal (Outputs) that contains all the outputs from the mode logic. The bus signals are 
defined using the Simulink Bus Editor and bus selectors are used to extract individual signals 
that are used to define each property. Note that either inputs or outputs for the Mode Logic can 
be used as inputs for a specific property. 

The No Higher Event block outputs a bus signal that contains signals such as 
No_Higher_Event_Than_HDG_Switch_Pressed. These signals serve the same purpose they did 
in the Lustre specification - to independently specify the event prioritization logic in a form that 
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supports the succinct specification of mode logic properties. In this example, the signal 
No Higher _Event_Than_NAV_Capture_Cond_Met is being selected from the bus signal and 
input to the property specified in Figure 1 19. 

The actual model that is analyzed with Design Verifier is shown in Figure 122. This model 
contains the Mode Logic model itself and the property subsystem block of Figure 121. It only 
has one input, the bus signal for the Mode Logic inputs. The individual inputs for the Mode 
Logic are extracted using bus selector blocks and input to the Mode Logic. The outputs from the 
Mode Logic are collected into a bus signal using a bus creator block. The Mode Logic input and 
output bus signals are then fed into the property subsystem block. If desired, several property 
subsystem blocks with different subsets of the Mode Logic properties could be created. 

When the “Prove Properties” function of Design Verifier is invoked on this model, Design 
Verifier attempts to prove each proof obligation identified with a Proof Objective block or a 
sldv.prove command. Design Verifier will create a detailed analysis report of the results. The 
user can also request that a harness model be created to support the more detailed analysis of 
counterexamples. 

The examples available with this report include Simulink specifications of ten of the 118 Mode 
Logic properties. Development and verification of the other 108 properties are left as an exercise 
for the reader. 
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Figure 122 - Top-Most Model (Design Verifier) 
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5 Case Study: Abstract Interpretation 

This section illustrates the use of abstract interpretation to verify the correctness of the source 
code implementation of one of the flight control modes for the example system. The Heading 
Control Law source code consists of C code generated from a Simulink model of the controller. 
We will check a variety of non-functional properties related to the run-time behavior of the code 
using the Polyspace and Astree abstract interpretation tools. 

The rest of the chapter is organized as follows. Section 5.1 provides an overview of the Heading 
Control model and the source code generated from it. It also describes the kinds of properties 
that will be checked by abstract interpretation. Section 5.2 describes the software verification 
plan for the Heading Control source code, identifying the life-cycle data items to be produced, 
the DO-178C objectives to be satisfied, and tool qualification issues. Sections 5.3 and 5.4 
describe the fonnal verification results using Astree and Polyspace, respectively. 

5.1 Overview of the Heading Control Model 

The Heading Control Law is one of the flight modes in the FGS that is selected by the mode 
logic. It computes aileron, elevator, rudder, and throttle commands based on sensor inputs and 
commanded aircraft heading, altitude, and speed. For this case study, we have used a publicly 
available model provided by researchers at the University of Minnesota (UMN). A detailed 
description of the model and its use in an Unmanned Aerial Vehicle (UAV) flight test platform 
can be found in [3]. The complete flight software implemented by UMN consists of a sensor 
data acquisition module, a navigation module, a guidance law, a main control law, and a number 
of other modules associated with sensor faults and system identification. The heading control 
law that we are using is one mode available in the main control law. It is comparable in many 
ways to flight control laws that would be found in commercial aircraft. The other functions of 
the UMN flight test platfonn would be carried out by other parts of our example system. 

5.1.1 Heading Control Model and Code 

The heading control software is implemented as a single thread that executes at 50Hz. The 
design is implemented as a two-tiered structure with inner and outer control loops (Figure 123). 
The inner loop controller (shown in blue) tracks the desired pitch (theta) and roll (phi) angles of 
the aircraft while damping out oscillations present in the open-loop dynamics. It responds to 
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inputs produced by the three outer loop controllers. The Altitude Tracker produces a pitch angle 
reference command, and the Velocity Tracker produces a throttle command. Both the Altitude 
Tracker and Velocity Tracker use proportional-integral control and implement integrator anti- 
windup logic to safely limit the commands provided to the inner loop control system. The 
throttle command is constrained between 0 and 1 , and the pitch angle reference is constrained to 
±20°. The heading controller (Psi Tracker) uses proportional gain, and the roll angle reference is 
constrained directly at ±45°. This limiting is required to prevent the aircraft from rolling over due 
to large ground track angle step commands. 
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Figure 123 - Heading Control Law Model 

The MATLAB Real-Time Workbench (RTW) was used to generate C code for the heading 
control model. The target platform selected to generate the source code for the Simulink model 
was the Embedded Real Time (ERT) target environment. RTW generated library files, header 
files, the heading_control.c and ertjnain.c. The heading_control.c and the ertjnain.c were 
included as the source files in the Polyspace project. The C header files also had to be included 
in the project to run the verification successfully. RTW generates functions for each block in the 
Simulink model. There are 856 lines of code in heading control. c and 101 lines of code in 
ertjnain.c. A fragment of the C code for heading control. c is shown in Figure 124. 
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/* 

* File: heading^control . c 

•k 

* Code generated for Simulink model ' heading_control ' . 

•k 

* Model version : 1.153 

* Simulink Coder version : 8.1 (R2011b) 08-Jul-2011 

* TLC version : 8.1 (Jul 9 2011) 

* C/C++ source code generated on : Fri Mar 01 16:24:21 2013 

■k 

* Target selection: ert.tlc 

* Embedded hardware selection: Generic->32-bit x86 compatible 

* Code generation objectives: Unspecified 

* Validation result: Not run 
*/ 

finclude "heading_control . h" 
finclude "heading_control_private . h" 

/* user code (top of source file) */ 

# include Software /Flight Code/ control/ rtw_grt_control . c" 

/* Block signals (auto storage) */ 

BlockIO_heading_control heading_control_B; 

/* Block states (auto storage) */ 

D_Work heading_control heading control_DWork; 

/* External inputs (root inport signals with auto storage) */ 

Externallnputs heading^control heading_control_U; 

/* External outputs (root outports fed by signals with auto storage) */ 
ExternalOutputs_heading control heading^control Y; 

/* Real-time model */ 

RT_MODEL_heading_control heading_control_M_; 

RT_MODEL_heading_control *const heading_control_M = &heading_control_M_; 

/* Model step function */ 
void heading_control_step (void) 

{ 

real T denAccum; 
real_T u; 
real_T u_0 ; 

/* Discretelntegrator : ' <S3>/Discrete-Time Integrator' */ 

heading^control B . DiscreteTimelntegrator = 

heading_control_DWor k . DiscreteTimelntegrator^DSTATE; 

/* Gain: '<S3>/Gainl' */ 

heading^control B.Gainl = 0.04 * heading_control B . DiscreteTimelntegrator ; 

/* DiscreteTransferFcn : ' <S3>/Discrete Transfer Fen' */ 

denAccum = 0.0392 * heading^control DWork . DiscreteTransf erFcn_DSTATE ; 

heading^control B. DiscreteTransferFcn = denAccum; 

Figure 124 - Fragment of Autogenerated C Code for Heading Control Model 
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5.1.2 Properties to Be Checked 

Abstract interpretation is a technique which can be applied at the source code level in order to 
prove the absence of runtime errors including division by zero, arithmetic overflow, and out-of- 
bounds array indexing. This kind of non-functional requirement is in general difficult to verily 
using testing, since runtime errors might only occur under certain very special circumstances that 
are not exposed in any test case. In contrast, abstract interpretation can guarantee that certain 
classes of runtime errors cannot occur under any circumstances. 

Typical run-time errors that can be detected by abstract interpretation include: 

• Unreachable code 

• Out of bounds array index 

• Division by zero 

• Non-initialized variables 

• Scalar and float overflows 

• Uninitialized return value 

• Shift operation errors 

• Illegal pointer dereferencing 

• Non-initialized pointers 

• User assertions 

• Non-termination of call 

• Non-termination of loop 

• Standard library function call error 

Roughly speaking, abstract interpretation tools compute over-approximations of the set of all 
possible executions of a given program. This means that the tool does not only consider program 
executions which can really occur, but also executions which cannot occur because they would 
not respect the relations which exist between certain variables of a program. This is often 
referred to as the precision of an analysis: higher precision is more difficult to achieve, but 
means that there are fewer impossible executions which are included in the analysis. 

A low precision analysis is easier to achieve. However, in this case the analyzer might indicate 
that a runtime error could happen at a certain point in a program, but none of the program 
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executions which can really occur will provoke this error. Such errors are called false alarms, 
and if they occur, the precision of the analysis must be increased by user interaction. A tool that 
produces a high number of false alarms not only results in an increased workload, but is 
annoying to use and is likely to be rejected by developers. 

5.2 Software Verification Plan 

In this case study, we will use abstract interpretation to verify the outputs of the software coding 
and integration process. In the example, this corresponds to verification that the source code 
implementing the Heading Control Law is correct. Current abstract interpretation tools are best 
suited to checking for run-time errors in the code rather than satisfaction of behavioral 
requirements, so this is where we will focus our effort. The purpose of these verification 
activities is to detect any errors that may have been introduced during the software coding 
process. 

Verification will be perfonned on source code generated from the Simulink control law model. 
Our primary objective is to check the code for accuracy and consistency (DO-333 Section 
6.3.4.f). We can also check for unreachable code. We assume that the code will be tested 
against high and low level requirements-based test cases as part of a traditional test-based 
verification process. 

Astree is a C code analysis tool which has been developed by the team of Professor Patrick 
Cousot at the Ecole Nonnale Superieure in Paris [2] in close cooperation with Airbus. Therefore, 
Astree provides some analysis capabilities which have been designed especially for real-time 
control software such as the code generated from SCADE models. In recent years, Astree has 
been commercialized by the Gennan company Abslnt, and features for the analysis of more 
general programs have been added, as well as a powerful GUI [1], 

An example of a feature which enables the proof of absence of overflow errors in control 
applications is the so-called filter domain, which is able to express invariants of first and second 
order filters implemented by the analyzed code. Typically, filters have invariants in the form of 
ellipsoids, which cannot be described by linear expressions. Astree tries to find patterns in the 
code which correspond to filters, and then uses the filter domain to compute invariants, taking 
into account that floating-point rounding errors can occur. 
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Polyspace is a commercial static analysis tool based on abstract interpretation and sold by 
MathWorks. It verifies both C and C++ code. Polyspace identifies the potential for overflow, 
divide by zero, out of bound array access, and other runtime errors. Polyspace provides some 
support for automated analysis to check compliance with the Software Architecture. It also 
supports compliance checking of the software against coding standards. 

Since some runtime errors are dependent on the target CPU and operating system, the user must 
specify the type of CPU and operating system used in the target environment before running a 
verification. Other configuration parameters support tailoring of the precision of the analysis: 

• Precision Level: This identifies the abstraction algorithm that is used to model the state of 
the program that is to be verified. It provides a trade-off between precision and analysis 
time. 

• Verification Level: This indicates the Software Safety Analysis Level (0-4). This 
specifies how many times the abstract interpretation algorithm passes through the code. 
The deeper the verification goes the more precise it is. Each iteration results in a deeper 
level of propagation of calling and called context. 

Polyspace can perform verification against some coding standards, such as MISRA C. This 
includes enforcing naming conventions checking for implicit type conversions, and detecting 
other error-prone coding practices. The tool has features to select only some rules among the set 
of all the available custom rules. 

Polyspace provides some limited support to verify compliance with the software architecture. It 
generates a call tree that must be manually checked to see if it preserves the software architecture 
of the original model. It also detennines the procedures and functions that have not been used. 

There are also several open source abstract interpretation tools available, but which are outside 
the scope of this case study. Frama-C [6] is a suite of static analysis tools for software written in 
C. Its Value Analysis plugin uses abstract interpretation to compute a set of possible values for 
each variable in a program, and operates in both automatic and user-guided modes. IKOS is a 
C++ library designed to facilitate the development of sound static analyzers based on Abstract 
Interpretation [16]. IKOS provides a generic and efficient implementation of state-of-the-art 
Abstract Interpretation data structures and algorithms, such as control-flow graphs, fixpoint 
iterators, numerical abstract domains, etc. 
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5.2.1 Life Cycle Data Items 

Low-Level Software Requirements The low-level software requirements are specified as a 
MATLAB Simulink model in the file heading control. mdl, along with model libraries 
Controller Lib. mdl and Actuator Lib. mdl, and a collection of associated scripts. 

Source Code The source code to be analyzed is C code autogenerated from the Simulink Low- 
Level Requirements using the MathWorks RTW. The code is contained in the files ertjnain.c, 
heading_control.c, and heading_control.h, along with several other header files. 

No separate behavioral requirements are verified in this case study. Abstract interpretation is 
being used to verify a standard set of run-time properties of C code. 

5.2.2 Objectives to Be Satisfied 

The DO-178C and DO-333 objectives to be satisfied through abstract interpretation are 
summarized in Table 49. A more detailed discussion of how each objective is satisfied is 
provided in this section. 
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Table 49 - Summary of Objectives Satisfied by Abstract Interpretation 


Objective 

Description 

A 

B 

c 

D 

Notes 

A-5.1 

Source Code complies with 
low level requirements. 





Not addressed 

A-5.2 

Source Code complies with 
software architecture. 





Not addressed 

A-5.3 

Source Code is verifiable. 

□ 

T 


This may be partially satisfied by demonstrating 
that the code conforms to input restrictions for the 
analysis tool. 

A-5.4 

Source Code conforms to 
standards 

□ 

□ 

□ 


This may be partially or fully satisfied by different 
analysis tools, depending upon the coding 
standards and tool qualification. 

A-5.5 

Source Code is traceable to 
low-level requirements. 





Not addressed 

A-5.6 

Source Code is accurate and 
consistent. 

□ 

□ 

□ 


The absence of some classes of run-time errors is 
established through analysis with abstract 
interpretation tools. 

A-5.7 

Output of software integration 
process is complete and 
correct. 





Not addressed 

A-5.8 

Parametric Data Item File is 
correct and complete. 





Not addressed 

A-5.9 

Verification of Parametric Data 
Item File is achieved. 





Not addressed 

FM.A-5.10 

Formal analysis cases and 
procedures are correct. 

■ 

■ 

■ 


Established as part of tool qualification 

FM.A-5.1 1 

Formal analysis results are 
correct and discrepancies 
explained. 

■ 

■ 

■ 


Established by review 

FM.A-5.12 

Requirements formalization is 
correct. 

■ 

■ 

■ 

_ 

Established as part of tool qualification 

FM.A-5.13 

Formal method is correctly 
defined, justified, and 
appropriate. 

■ 

■ 

■ 

_ 

■ 

Established by review 


■ Full credit claimed □ Partial credit claimed Satisfaction of objective Is at applicant’s discretion 


Objective A-5.3 - Source Code is verifiable. This objective is met by demonstrating that the code 
to be analyzed conforms to any input restrictions of the analysis tool, and that it was, in fact, 
accepted by the tool. Any portion of the code that does not confonn to the tool restrictions or 
that is not processed by the tool for some other reason will have to be verified by some other 
method. 

Objective A-5.4 - Source Code conforms to standards. Some abstract interpretation tools will 
check conformance to standard or user-defined coding rules. This may be used to fully or 
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partially satisfy the objective, depending upon the particular coding standards to be enforced. 
Tool qualification for checking conformance to standards would also be required. 

Objective A-5.6 - Source Code is accurate and consistent. This objective is met by verifying the 
absence of run-time errors in the Source Code using an abstract interpretation tool. False alarms 
generated by the tool must be justified by separate analysis or testing. Any portion of the code 
for which the tool provides an “indeterminate” result must be verified through other methods. 

Objective FM.A-5.10 Formal analysis cases and procedures are correct. This objective is met 
through review to ensure that the analyses and procedures satisfy the objectives for which credit 
is claimed. Since the properties to be checked are defined implicitly in the analysis tool, some 
aspects of tool qualification will be used to satisfy this objective. 

Objective FM.A-5.11 Formal analysis results are correct and discrepancies explained. This 
objective is met through review of the analysis results to ensure that all of the code has been 
analyzed, and that any false alanns or indeterminate results from the tool have been justified 
through reviews or further analysis. 

Objective FM.A-5.12 Requirements formalization is correct. This objective is met through tool 
qualification since the properties to be checked are implicit in the tool itself. 

Objective FM.A-5.13 Formal method is correctly defined, justified, and appropriate. This objective 
is met through a review to ensure: 

a. All notations used for fonnal analysis are verified to have precise, unambiguous, 
mathematically defined syntax and semantics. Abstract interpretation methods are based 
upon the formal semantics of the programming language to be analyzed. 

b. The soundness of each formal analysis method is justified. Abstract interpretation tools 
may return an “indeterminate” result for some portions of the code, meaning that the tool 
was unable to conclusively determine that code to be error-free. Evidence of soundness 
should be provided through citations to publications addressing basis of soundness for the 
underlying analysis method. 

c. Assumptions related to each formal analysis are described and justified. It is typical for 
proof of the absence of over/underflow to hold only if the program inputs stay within 
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defined ranges. These bounds are assumptions that must be documented, as described in 
the case study analysis. 

In this case study, we have primarily demonstrated use of abstract interpretation for a specific 
objective, the absence of runtime errors as required by objective A-5.6, Source Code is accurate 
and consistent. The software tools we have used may also be used to partially satisfy a number 
of other objectives, including objectives related to Executable Object Code (EOC). In general, 
taking credit for EOC objectives in Table FM.A-6 based on activities perfonned on the source 
code requires that the equivalence of EOC and source code be established (see DO-333 
paragraph 6.7.f). 

Abstract interpretation tools have also been used to compute worst case execution time and stack 
usage. These analyses may be useful in satisfying other objectives such as those specified in 
FM.6.7.e and FM.A-6. 5, Executable Object Code is compatible with target computer. These 
evaluations are outside the scope of the current case study. 

5.2.3 Tool Qualification Issues 

A DO-178C/DO-330 tool qualification kit is available for Polyspace from the vendor, 
MathWorks. MathWorks provides artifacts and evidence to support qualification under Criteria 
2 since they suggest that the tool may be used to reduce object code verification processes in 
addition to automating source code verification processes. If this tool is being used to verify 
Level A or B software, this would map to TQL-4, while for Level C or D software this would 
map to TQL-5. The Polyspace qualification kit includes development artifacts and an extensive 
list of TORs. Test cases are defined with input code for the errors that the tool is intended to 
detect. 

For Astree, a Qualification Support Kit (QSK) is available from its vendor, Abslnt. The currently 
available QSK can be used for qualification up to level A under DO-178B. 

5.3 Analysis of the Heading Control Law Source Code with Astree 

Astree can be used to prove that no overflow errors can occur during the execution of the control 
code, but this is only possible if the user does some fine-tuning in order to eliminate false alarms. 
This fine-tuning is done by indicating to Astree that at certain points in the program, different 
cases need to be distinguished, which is called partitioning in the terminology of Astree. To find 
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the places in the code where partitioning is needed, and to determine the conditions which 
distinguish the different cases in the partitioning, the user needs to have some understanding of 
the implemented system. 


Astree initially reported four potential issues (or alarms ) in the source code corresponding to C 
statements which might cause floating-point overflow errors. The Astree graphical user interface 
allows one to find the code line which corresponds to an alarm easily by clicking on the alarm 
message, as shown in Figure 125. 



Figure 125 - Astree Analysis Results 

The alarms can be explained as follows: The code of the control law implements four integrators, 
which are protected from overflow by anti-windup mechanisms. However, the abstraction made 
by Astree keeps the tool from detecting the effectiveness of the overflow prevention. To enable 
Astree to prove that these mechanisms are effective, the analysis needs to be guided by some 
partitioning information provided by the user. 

By analyzing the way the anti-windup-mechanism works, the necessary analysis partitions can 
be found. For every integrator, case distinctions need to be done according to two criteria: firstly, 
the case where the input value of the integrator is zero or positive must be distinguished from the 
case where the value is negative. Secondly, three cases must be distinguished depending on the 
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internal value of the integrator: the case where the value is within a certain interval must be 
distinguished from the case where it is above it and the case where it is below this interval. 

ASTREE_partition_control if (integrator > 25.01); 

ASTREE_partition_control if (integrator < -25.01); 

ASTREE_partition_control if (diffl < 0.0); 

suml = 0.04 * integrator + 0.15 * diffl; 

Figure 126 - Astree Directives to Define Partitions 

Astree is in general not able to provide direct feedback to show where the case partitions must be 
done, but this must be determined by the user. However, an experienced user can find the 
necessary fine-tuning relatively easily. Also, there is some hope that future versions of Astree 
will be able to handle this kind of program automatically, since new partitioning heuristics are 
being developed by Abslnt. However, it is not always possible to fine-tune the analysis in such a 
way that all false alarms disappear. 

Astree is also able to detect dead code, which is reported in the GUI by highlighting unreachable 
code lines. Astree has some powerful features to detect dead code by determining for example 
that a given condition will always be evaluated to a constant value. 

5.4 Analysis of the Heading Control Law Source Code with Polyspace 

A summary of the results obtains from applying Polyspace to the Heading Control Law source 
code is shown in Table 50. 


Table 50 - Initial Polyspace Analysis Results 


Run-Time Checks 


Polyspace Verifier 

Enabled 

Number of Result Sets 

x 1 

Number of Red Run-Time Checks 

0 

Number of Gray Run-Time Checks 


Number of Orange Run-Time Checks 


Number of Green Run-Time Checks 

478 

Proven 

97.4% 

Pass/Fail 

- 
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Possible runtime errors were detected in two categories indicated by color coding: Gray checks 
correspond to unreachable code and orange checks corresponding to unproven or potential 
runtime errors. No proven runtime errors (reported in red) were detected. 

For the unreachable code, Polyspace reports an error such as: 

if-condition always evaluates to false at line 779 (column 6) 
block ends at line 782 (column 2) 

Upon further investigation, it was determined that all of the unreachable code was the result of 
branch conditions in the anti-windup logic for the integrators which always evaluate to false. 
The model constant ‘gain sign’ is used to select a positive or negative value in the logic (see 
Figure 127). Therefore, once this constant is set in the application, the unused branch of the 
logic can be optimized away by either the code generator or the compiler, eliminating the 
unreachable code. 



The unproven orange checks all corresponded to potential floating-point overflow errors (Table 
51). Polyspace reports an error of the form: 
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heading_control_B . Suml = heading__control U . ref^cmds [ 1 ] 

OVFL.IO Unproven : operation [-] on float may overflow (on MIN or MAX bounds of 
FLOAT 6 4 ) 

If appropriate, applying Data Range Specification (DRS) to initialization of 
heading_control_U by the main generator, may remove this orange. 

If appropriate, applying DRS to initialization of heading_control DWork by the 
main generator, may remove this orange, 
operator - on type float 64 

left: full-range [-1 . 7977E +308 .. 1 . 7 97 7E +30S ] 

right: [-7.047E +306 .. 7.047E +306 ] 

result: full-range [-1 . 7977E +308 .. 1.7 977E +308 ] 

For the variables indicated, this means that it is not possible to guarantee that their values will 
not overflow unless some additional infonnation about the system is provided. Polyspace 
provides a mechanism to specify range limits on inputs to the system (Data Range Specification, 
or DRS). These limits can then be used to more precisely compute the actual range of the 
variables whose values are computed from these inputs. Once a DRS is set up for each of the 
system inputs, the potential overflow errors are eliminated. 

Table 51 - Unproven Runtime Checks 


Check 

Function 

Line 

Col. 

Detail 

Jus. 

Class 

Status 

OVFL.IO 

heading_control_step() 

65 

57 

Unproven : operation [-] 
on float may overflow 
(on MIN or MAX bounds 
of FLOAT64) 

No 




Polyspace can also be used to check code for conformance to standards. This can include 
standard coding rules (such as MISRA-C) or user-defined rules. This can be used to partially 
satisfy objective A-5.4, Source Code conforms to standards. To demonstrate, the heading 
control code was analyzed for conformance with the MISRA-C standard. The results are shown 
in Table 52. 


Table 52 - Coding Rules Analysis 


File 

Warnings 

Errors 

Total 

C:\rw_apps\polyspace_workspace\Heading_Control\source\heading_control.c 

278 

0 

278 

C:\rw_apps\polyspace_workspace\Heading_Control\include\rtwtypes.h 

16 

0 

16 

Total 

294 

0 

294 
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6 Conclusion 


The three case studies in this report illustrate the use of different formal methods tools to satisfy 
the certification objectives defined in DO-178C and its accompanying formal methods 
supplement, DO-333. These case studies provide a practical demonstration of theorem proving, 
model checking, and abstract interpretation applied to a Flight Guidance System design that is 
representative of systems deployed in commercial aircraft. The case studies show how the 
evidence produced by these three techniques might be used in an actual certification effort. Each 
technique has strengths and weaknesses and each could be applied to different life cycle data 
items and different objectives from those described here. 

Formal methods and tools have already been used to a limited extent in several actual aircraft 
certification efforts. However, due to the proprietary nature of the models, code, and other 
artifacts, it has not been possible to make these results public. We hope that by providing a 
collection of publicly available examples, our case studies will be useful to industry and 
government personnel in understanding both the new certification guidance in DO-333 and the 
benefits that can be realized through the use of fonnal methods. 
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Appendix A Acronyms 


ADS 

Air Data System 

AFDX 

Avionics Full-Duplex Switched Ethernet 

AHRS 

Attitude Heading Reference System 

ALT 

Altitude Hold Mode 

ALTSEL 

Altitude Select Mode 

APPR 

Approach 

AP 

Autopilot 

BDD 

Binary Decision Diagram 

DCP 

Display Control Panel 

DRS 

Data Range Specification 

EOC 

Executable Object Code 

ERT 

Embedded Real Time 

FCP 

Flight Control Panel 

FCS 

Flight Control System 

FGS 

Flight Guidance System 

FD 

Flight Director 

FGS 

Flight Guidance System 

FLC 

Flight Level Change Mode 

FMS 

Flight Management System 

GA 

Go Around 

HDG 

Heading Hold Mode 

HOL 

Higher Order Logic 

IAS 

Indicated Airspeed 
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ILS 

Instrument Landing System 

LAPPR 

Lateral Approach Mode 

LGA 

Lateral Go Around Mode 

NAV 

Lateral Navigation Mode 

PFD 

Primary Flight Display 

PITCH 

Pitch Hold Mode 

QSK 

Qualification Support Kit 

ROLL 

Roll Hold Mode 

RTW 

Real-Time Workbench 

SMT 

Satisfiability Modulo Theories 

TCC 

Type-Correctness Condition 

TOR 

Tool Operational Requirements 

TQL 

Tool Qualification Level 

TTA 

Time-Triggered Architecture 

UAV 

Unmanned Aerial Vehicle 

UMN 

University of Minnesota 

VAPPR 

Vertical Approach Mode 

VGA 

Vertical Go Around Mode 

VS 

Vertical Speed Mode 
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Appendix B Mode Logic Properties 


— SAFETY PROPERTIES 


-- At least one lateral mode shall always be active 
-- when the FD is displayed or the AP is engaged. 


At Least_One_Lateral_Mode_Active = 

ROLL^Active or HDG_Active or NAV_Active or LAPPR_Active or LGA_Active; 
check At Least One Lateral Mode Active; 


-- At most one lateral mode shall be active 
-- when the FD is displayed or the AP is engaged. 


At_Most_One_Lateral_Mode__Active = 
(ROLL_Active => 


not ( 

(HDG_Active => 

not (ROLL^Active 
(NAV_Active => 

not (ROLL^Active 
(LAPPR_Active => 

not (ROLL^Active 
(LGA_Active => 

not (ROLL^Active 


HDG_Active or NAV_Active 
or NAV_Active 

or HDG_Active or 
or HDG_Active or NAV_Active 
or HDG Active or NAV Active 


or LAPPR_Active 
or LAPPR_Active 
LAPPR_Active 
or 

or LAPPR Active 


or LGA_Active) 
or LGA_Active) 
or LGA_Active) 
LGA_Active) 
) 


and 

and 

and 

and 


check At Most One Lateral Mode Active; 


-- At least one vertical mode shall always be active 
-- when the FD is displayed or the AP is engaged. 


At Least_One_Vertical_Mode_Active = 

PITCH_Active or VS_Active or FLC_Active or ALT_Active or ALTSEL_Active or 
VAPPR_Active or VGA_Active; 

check At Least One Vertical Mode Active; 


-- At most one vertical mode shall be active 
-- when the FD is displayed or the AP is engaged. 


At Most One Vertical Mode Active = 


(PITCH Active => 

not ( 


VS Active or 

VAPPR Active 

or 

VGA Active) ) 

(VS Active => 

not (PITCH Active 

or 


VAPPR Active 

or 

VGA Active) ) 

( FLC Active => 

not (PITCH Active 

or 

VS Active or 

VAPPR Active 

or 

VGA Active) ) 

(ALT Active => 

not (PITCH Active 

or 

VS Active or 

VAPPR Active 

or 

VGA Active) ) 


( ALTSEL_Act ive => 


FLC_Active or ALT_Active or ALTSEL_Active 
and 

FLC_Active or ALT^Active or ALTSEL_Active 
and 


and 


ALT Active or ALTSEL Active 


FLC_Active or ALTSEL_Active 

and 


or 


or 


or 


or 
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not (PITCH Active 

or 

VS Active or 

FLC 

Active 

or 

ALT 

Active 

or 



VAPPR Active 

or 

VGA Active) ) 

and 








(VAPPR Active => 











not (PITCH Active 

or 

VS Active or 

FLC 

Active 

or 

ALT 

Active 

or 

ALTSEL 

Active or 



VGA Active) ) 

and 








(VGA Active => 











not (PITCH Active 

or 

VS Active or 

FLC 

Active 

or 

ALT 

Active 

or 

ALTSEL 

Active or 


VAPPR_Active ) ) ; 

check At Most One Vertical Mode Active; 


-- VGA mode shall be active if LGA mode is active (except for one step) . 


LGA_Active_Implies_VGA_Active = 

pre LGA_Active and LGA_Active => pre VGA_Active; 

check LGA_Active_Implies_VGA_Active ; 


-- LGA mode shall be active if VGA mode is active (except for one step) . 


VGA_Active_Implies_LGA_Active = 

pre VGA_Active and VGA^Active => pre LGA_Active; 

check VGA_Active_Implies LGA_Active; 


-- VAPPR mode shall be active only if LAPPR mode is active (except for one step) . 


VAPPR_Act ive_Implies_LAPPR_Active = 

pre VAPPR_Active and VAPPR_Active => pre LAPPR_Active ; 

check VAPPR_Active_Implies_LAPPR_Active ; 


— FLC , ALT, ALTSEL, or PITCH mode shall be active 
-- while an overspeed condition exists. 


Overspeed_Implies_FLC_ALT_ALTSEL_PITCH = 

Overspeed => FLC_Active or ALT^Active or ALTSEL^Active or PITCH_Active; 

check Overspeed_Implies_FLC_ALT_ALTSEL_PITCH; 


-- PITCH mode shall be active for only one step while an overspeed condition exists. 

Overspeed_and_PITCH_Transitiory = true -> 

pre PITCH_Active and Overspeed => not PITCH__Active ; 

check Overspeed and_PITCH_Transitiory ; 
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— FUNCTIONAL PROPERTIES 


— MODE ANNUNCIATIONS 


-- The mode annunciations shall be off at system start up. 


Modes_Of f_At_Startup = 
not Modes_On -> true; 

check Modes_Of f__At_Startup; 


-- The mode annunciations shall be on if the AP is engaged. 


AP_Engaged Implies_Modes_On = true -> 
Is_AP_Engaged => Modes_On; 

check AP_Engaged_Implies_Modes_On ; 


-- The mode annunciations shall be on if the offside FD is on. 

Of f side_FD_On_Implies_Modes_On = true -> 

Offside FD_On => Modes_On; 

check Of f side_FD_On_Implies_Modes_On; 


-- The mode annunciations shall be on if the onside FD is on. 


Onside_FD_On_Implies_Modes_On = 
FD_On => Modes_On; 

check Onside_FD_On_Implies_Modes_On ; 


-- The mode annunciations shall be on if and only if the onside FD is on, 
-- the offside FD is on, or the AP is engaged. 


Modes_On_If f_FD_On_or_AP_Engaged = true -> 

Modes_On = (FD__On or Of fside_FD_On or Is_AP_Engaged) ; 

check Modes_On Iff FD_On_or_AP_Engaged; 


— FLIGHT DIRECTOR 


-- The onside FD shall be off at system start up 
FD_Of f__At_Startup = (not FD_On -> true) ; 
check FD_Of f_At_Startup; 

-- The onside FD shall turn on when the FD switch is pressed. 
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FD_Switch Turns_FD_On = 

not pre FD_On and RISING (FD_Switch) 

and No_Higher_Event Than__FD_Switch_Pressed => FD_On; 
check FD_Switch_Turns_FD_On; 

-- The onside FD shall turn on when the AP is engaged. 

AP_Engaged_Turns_FD_On = 

RISING (Is_AP_Engaged) => FD_On ; 

check AP_Engaged Turns_FD_On; 

-- The onside FD shall be on when an overspeed condition exists. 

Overspeed Implies_FD_On = true -> 

Overspeed => FD_On; 

check Overspeed__Implies FD_On; 

-- The onside FD shall turn on when the HDG switch is pressed. 
HDG_Switch_Turns FD_On = 

RISING (HDG_Switch) and No_Higher_Event_Than_HDG_Switch Pressed => FD_On; 
check HDG_Switch Turns_FD_On; 

-- The onside FD shall turn on when the NAV switch is pressed. 
NAV_Switch_Turns_FD_On = 

RISING (NAV_Switch) and No_Higher_Event_Than_NAV_Switch Pressed => FD_On; 
check NAV_Switch Turns_FD_On; 

-- The onside FD shall turn on when the APPR switch is pressed. 
APPR_Switch_Turns_FD_On = 

RISING (APPR_Switch) and No_Higher_Event_Than_APPR_Switch_Pressed => FD_On; 
check APPR_Switch Turns FD_On; 

-- The onside FD shall turn on when the GA switch is pressed. 

GA_Switch Turns_FD_On = 

RISING (GA_Switch) and No_Higher_Event Than_GA_Switch_Pressed => FD_On; 
check GA_Switch_Turns_FD_On; 

-- The onside FD shall turn on when the VS switch is pressed. 

VS_Switch Turns_FD_On = 

RISING (VS_Switch) and No_Higher_Event Than_VS_Switch_Pressed => FD_On; 
check VS Switch Turns FD On; 
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-- The onside FD shall turn on when 

the 

FLC 

switch 

is pressed. 

FLC Switch Turns FD On = 

RISING (FLC Switch) and No Higher 

Event Than FLC 

Switch Pressed => FD On; 

check FLC Switch Turns FD On; 





-- The onside FD shall turn on when 

the 

ALT 

switch 

is pressed. 


ALT_Switch_Turns_FD_On = 

RISING (ALT_Switch) and No_Higher_Event Than_ALT_Switch_Pressed => FD__On; 
check ALT Switch Turns FD On; 


-- The onside FD shall turn on when the VS Pitch Wheel is rotated 
-- while this side is active and VS and VAPPR mode are not active 
-- and an overspeed condition does not exist. 


VS_Pitch_Wheel_Rotated Turns_FD_On = 

RISING (VS_Pitch_Wheel_Rotated) 
and pre Active_Side 

and not pre VS_Active and not pre VAPPR_Active 
and not Overspeed 

and No_Higher_Event Than_VS_Pitch_Wheel_Rotated => FD_On; 
check VS Pitch Wheel Rotated Turns FD On; 


-- The onside FD shall turn on when the ALTSEL target altitude is changed 
-- while this side is active and ALTSEL mode is active. 


ALTSEL_Target_Changed_Turns_FD_On = 

RISING (ALTSEL Targe t_Changed) and pre Active_Side and pre ALTSEL_Active 
and No_Higher_Event Than_ALTSEL_Target Changed => FD_On; 

check ALTSEL Target_Changed Turns_FD_On; 


-- The onside FD shall turn on when there is a pilot flying transfer 
-- to this side of the aircraft while the mode annunciations are on. 


Pilot Flying Transfer_While_Modes_On_Turns_FD_On = 

pre not FD_On and pre Modes_On and RISING (Pilot Flying^Side) => FD_On; 

check Pilot_Flying Transfer_While_Modes_On_Turns_FD_On; 


-- The onside FD shall turn off when the FD switch is pressed 
-- while an overspeed condition does not exist. 


FD_Switch_Turns_FD_Of f = 

pre FD_On and RISING (FD_Switch) and not Overspeed 

and No_Higher_Event_Than_FD_Switch_Pressed => not FD_On; 

check FD Switch Turns FD Off; 
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-- Disengaging the AP shall not turn off the FD unless the FD switch is pressed 

FD_Stays_On_When_AP_Disengaged = true -> 

pre FDjDn and not FALLING ( I s_AP_Engaged) and not RISING (FD_Switch) => FDjDn; 

check FD_St ay s_On_When_AP_D is engaged; 


-- The onside FD shall not turn off unless the FD switch is pressed. 

FD_Stays_On_Unless_FD_Switch_Pressed = true -> 
pre FDjDn and not RISING (FD_Switch) => FD_On ; 

check FD_Stays_On_Unless_FD_Switch_Pressed; 

— INDEPENDENT MODE 


-- Independent mode shall be active when VAPPR mode is active on both sides. 

Both_Sides_VAPPR_Active Implies_Independent_Mode = true -> 

pre VAPPR_Active and Is_Of f side_VAPPR_Active => Independent_Mode ; 

check Both_Sides_VAPPR_Active_Implies_Independent_Mode ; 


-- Independent mode shall be active when VGA mode is active on both sides. 

Both_Sides_VGA_Active_Implies_Independent_Mode = true -> 

pre VGA_Active and Is_Of f side_VGA_Active => Independent_Mode ; 

check Both_Sides_VGA_Active_Implies_Independent_Mode ; 


-- Independent mode shall imply either VAPPR or VGA is active on both sides. 


Independent_Mode_Implies_Both_VAPPR_or_VGA_Active = 
Independent_Mode => 

(pre VAPPR_Active and Is_Of fside_VAPPR_Active) or 
(pre VGA_Active and Is_Of fside_VGA_Active) ; 

check Independent_Mode_Implies_Both_VAPPR_or_VGA_Active ; 


— ACTIVE SIDE 


-- This side shall be active iff it is in independent mode or the pilot flying side. 


Active_iff Independent_or_Pilot Flying = 

Active_Side = Independent_Mode or Pilot Flying_Side; 

check Active_if f_Independent_or_Pilot Flying; 


— ROLL MODE 
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-- ROLL mode shall be active if and only if ROLL mode is selected. 


ROLL_Selected_I f f_ROLL_Active = 
(ROLL^Active = ROLL_Selected) ; 

check ROLL Selected Iff ROLL Active; 


-- ROLL mode shall be active iff no other lateral mode is active. 


Default Lateral_Mode Is_ROLL = true -> 

ROLL Active = 

not (HDG_Active or NAV_Active or LAPPR_Active or LGA_Active) ; 
check Default Lateral Mode Is ROLL; 


-- ROLL mode shall be active if the mode annunciations are off. 

Modes_Off Implies_ROLL_Active = true -> 
not Modes_On => ROLL__Active ; 

check Modes_Off Implies_ROLL_Active ; 


-- ROLL mode shall be active if the FD switch is pressed 
-- while the mode annunciations are off. 


FD_Switch_Pressed_Modes_Of f Implies_ROLL Active = 
not Modes_On and RISING (FD_Switch) 

and No_Higher_Event_Than_FD_Switch_Pressed => ROLL^Active; 
check FD_Switch_Pressed_Modes_Of f Implies_ROLL_Active ; 


-- ROLL mode shall be active if the AP is engaged 
-- while the mode annunciations are off. 


AP_Engaged_Modes_Of f Implies_ROLL_Active = 

not Modes_On and RISING (Is_AP_Engaged) => ROLL_Active; 

check AP_Engaged_Modes_Of f_Implies_ROLL_Act ive ; 


— HDG MODE 


-- HDG mode shall be selected if and only if HDG mode is active. 


HDG_Selected_If f_HDG_Active = 
HDG_Active = HDG_Selected; 

check HDG Selected Iff HDG Active; 


-- HDG mode shall be selected if the HDG switch is pressed while HDG mode is cleared. 


HDG_Switch Pressed_Selects_HDG = 

not pre HDG_Selected and RISING (HDG_Switch) 
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and No_Higher_Event Than_HDG_Switch_Pressed => HDG_Selected; 
check H DG_S wit ch_Pr esse d_Selects_HDG; 

-- HDG mode shall be cleared if the HDG switch is pressed while HDG mode is selected. 

HDG_Switch_Pressed_Clears_HDG = 

pre HDG_Selected and RISING (HDG_Switch) 

and No_Higher_Event_Than_HDG_Switch_Pressed => not HDG_Selected; 
check HDG_Switch Pressed_Clears_HDG; 

-- HDG mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_HDG = 

pre HDG_Selected and CHANGED ( Pilot Flying_Side) => not HDG_Selected; 
check Pilot Flying^Transf er_Clears_HDG; 

-- HDG mode shall be cleared when the mode annunciations are turned off. 

Modes_Of f_Clears_HDG = 

pre HDG_Selected and not Modes_On => not HDG_Selected; 
check Modes_Of f_Clears_HDG; 

— NAV MODE 


-- NAV mode shall be selected if NAV mode is active. 


NAV_Selected_If_NAV_Active = 

NAV_Active => NAV_Selected; 

check NAV Selected If NAV Active; 


-- NAV mode shall be selected if the NAV switch is pressed while NAV mode is cleared. 


NAV_Switch_Pressed_Selects_NAV = 

not pre NAV_Selected and RISING (NAV_Switch) 

and No_Higher_Event_Than_NAV_Switch Pressed => NAV_Selected; 
check NAV Switch Pressed Selects NAV; 


-- NAV mode shall become active if the NAV capture condition is met 
while NAV mode is armed. 


NAV_Active_When_Capture_Cond_Met = true -> 
pre NAV_Selected and not pre NAV_Active 
and NAV_Capture_Cond_Met 
and not Selected NAV_Source_Changed 
and not Selected_NAV_Frequency_Changed 
and not CHANGED ( Pilot_Fly ing_Side ) 
and Modes_On 

and No_Higher_Event Than_NAV_Capture_Cond_Met => NAV_Active; 
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check NAV_Active_When_Capture_Cond_Met ; 


-- NAV mode shall be cleared if the NAV switch is pressed while NAV mode is selected. 


NAV_Switch Pressed_Clears__NAV = 

pre NAV_Selected and RISING (NAV_Switch) 

and No_Higher_Event_Than_NAV_Switch Pressed => not NAV_Selected; 
check NAV Switch Pressed Clears NAV; 


-- NAV mode shall be cleared if the selected NAV source is changed. 


Selected_NAV_Source_Changed_Clears NAV = 
pre NAV_Selected 

and Selected NAV_Source_Changed => not NAV_Selected; 
check Selected_NAV_Source_Changed Clears_NAV; 


-- NAV mode shall be cleared if the selected NAV frequency is changed. 


Selected_NAV_Frequency_Changed_Clears_NAV = 
pre NAV_Selected 

and Selected_NAV_Frequency_Changed => not NAV_Selected; 
check Selected_NAV_Frequency_Changed_Clears_NAV; 


-- NAV mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_NAV = 

pre NAV_Selected and CHANGED ( Pilot Flying_Side) => not NAV_Selected; 
check Pilot Flying^Transf er_Clears_NAV; 

-- NAV mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears NAV = 

pre NAV_Selected and not Modes_On => not NAV_Selected; 
check Modes_Of f_Clears_NAV; 

— LAPPR MODE 


-- LAPPR mode shall be selected if LAPPR mode is active. 

LAPPR_Selected_If_LAPPR_Active = 

LAPPR_Active => LAPPR_Selected; 

check LAPPR Selected If LAPPR Active; 


-- LAPPR mode shall be selected if the APPR switch is pressed 
-- while LAPPR mode is cleared. 


APPR_Switch_Pressed_Selects_LAPPR = 

not pre LAPPR_Selected and RISING (APPR_Switch) 
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and No_Higher_Event_Than_APPR_Switch_Pressed => LAPPR_Selected; 
check APPR Switch Pressed Selects LAPPR; 


-- LAPPR mode shall become active if the LAPPR capture condition is met 
-- while LAPPR mode is armed. 


LAPPR_Active_When_Capture_Cond_Met = true -> 
pre LAPPR_Selected and not pre LAPPR_Active 
and LAPPR_Capture_Cond_Met 
and not Selected_NAV_Source_Changed 
and not Selected_NAV_Frequency_Changed 
and not CHANGED ( Pilot_Fly ing_Side ) 
and Modes_On 

and No_Higher_Event Than_LAPPR_Capture_Cond_Met => LAPPR_Active ; 
check LAPPR_Active_When_Capture_Cond_Met ; 


-- LAPPR mode shall be cleared if the APPR switch is pressed 
-- while LAPPR mode is selected. 


APPR_Switch_Pressed__Clears_LAPPR = 

pre LAPPR_Selected and RISING (APPR_Switch) 

and No_Higher_Event Than_APPR_Switch_Pressed => not LAPPR_Selected; 
check APPR Switch Pressed Clears LAPPR; 


-- LAPPR mode shall be cleared if the selected NAV source is changed. 

Selected_NAV_Source_Changed_Clears_LAPPR = 
pre LAPPR_Selected 

and Selected_NAV_Source_Changed => not LAPPR_Selected; 
check Selected_NAV_Source_Changed_Clears_LAPPR; 

-- LAPPR mode shall be cleared if the selected NAV frequency is changed. 

Selected__NAV_Frequency Changed_Clears_LAPPR = 
pre LAPPR_Selected 

and Selected_NAV_Frequency__Changed => not LAPPR_Selected; 
check Selected NAV_Frequency_Changed_Clears LAPPR; 

-- LAPPR mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_LAPPR = 

pre LAPPR_Selected and CHANGED (Pilot Flying^Side) => not LAPPR_Selected; 

check Pilot Flying^Transf er_Clears_LAPPR; 

-- LAPPR mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears LAPPR = 

pre LAPPR_Selected and not Modes_On => not LAPPR_Selected; 
check Modes Off Clears LAPPR; 
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— LGA MODE 


-- LGA mode shall be selected if and only if LGA mode is active. 


LGA_Selected_If f_LGA_Active = 
LGA_Active = LGA_Selected; 

check LGA Selected Iff LGA Active; 


-- LGA mode shall be selected if the GA switch is pressed while LGA mode is cleared 
-- and an overspeed condition does not exist. 


GA_Switch_Pressed_Selects_LGA = 

not pre LGA_Selected and RISING (GA_Switch) and not Overspeed 
and No_Higher_Event_Than_GA_Switch_Pressed => LGA_Selected; 

check GA Switch Pressed Selects LGA; 


-- LGA mode shall be cleared when the AP is engaged. 


AP_Engaged_Clears_LGA = 

pre LGA_Selected and RISING (Is_AP_Engaged) => not LGA_Selected; 
check AP_Engaged_Clears_LGA; 


-- LGA mode shall be cleared when VGA mode is cleared. 


VGA_Cleared_Clears_LGA = 

pre LGA_Selected and not pre VGA_Selected => not LGA_Selected; 
check VGA Cleared Clears LGA; 


-- LGA mode shall be cleared when the SYNC switch is pressed 
-- while LGA mode is selected. 


SYNC_Switch_Pressed_Clears_LGA = 

pre LGA_Selected and RISING (SYNC_Switch) => not LGA_Selected; 

check SYNC Switch Pressed Clears LGA; 


-- LGA mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_LGA = 

pre LGA_Selected and CHANGED ( Pilot Flying_Side) => not LGA_Selected; 

check Pilot_Flying_Transf er_Clears_LGA; 

-- LGA mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears LGA = 

pre LGA_Selected and not Modes_On => not LGA_Selected; 
check Modes Off Clears LGA; 
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PITCH MODE 


-- PITCH mode shall be active iff no other vertical mode is active. 


Default_Vertical_Mode_Is_PITCH = true -> 

PITCH_Active = not (VS_Active or FLC_Active or ALT_Active or 

ALTSEL_Active or VAPPR_Active or VGA_Active); 

check Default Vertical Mode Is PITCH; 


-- PITCH mode shall be active if the mode annunciations are off. 

Modes_Off Implies_PITCH_Active = true -> 
not Modes_On => PITCH_Active ; 

check Modes_Off Implies_PITCH_Active ; 


-- PITCH mode shall be active if the FD switch is pressed 
-- while the mode annunciations are off. 


FD_Switch_Pressed_Modes_Of f Implies_PITCH_Active = 
not Modes_On and RISING (FD_Switch) 

and No_Higher_Event_Than_FD_Switch_Pressed => PITCH_Active ; 
check FD_Switch_Pressed_Modes_Of f Implies_PITCH_Active ; 


-- PITCH mode shall be active if the AP is engaged 
-- while the mode annunciations are off. 


AP_Engaged_Modes_Of f Implies_PITCH_Active = 

not Modes_On and RISING ( I s_AP_Engaged) => PITCH_Active; 

check AP_Engaged_Modes_Of f_Implies_PITCH_Active ; 


— VS MODE 


-- VS mode shall be selected if and only if VS mode is active. 


VS_Selected_I f f_VS_Active = 

(VS_Active = VS_Selected) ; 

check VS Selected Iff VS Active; 


-- VS mode shall be selected if the VS switch is pressed while VS mode is cleared 
-- if VAPPR mode is not active and an overspeed condition does not exist. 


VS_Switch_Pressed_Selects_VS = 

not pre VS_Selected and RISING (VS_Switch) 
and not pre VAPPR_Active and not Overspeed 

and No_Higher_Event Than_VS_Switch_Pressed => VS_Selected; 
check VS Switch Pressed Selects VS; 
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-- VS mode shall be cleared if the VS switch is pressed while VS mode is selected. 


VS_Switch_Pressed_Clears_VS = 

pre VS_Selected and RISING (VS_Switch) 

and No_Higher_Event Than_VS_Switch_Pressed => not VS_Selected; 
check VS Switch Pressed Clears VS; 


-- VS mode shall be cleared when there is a pilot flying transfer. 


Pilot_Flying_Transf er_Clears_VS = 

pre VS_Selected and CHANGED (Pilot Flying^Side) => not VS_Selected; 
check Pilot_Flying Transf er_Clears_VS ; 


-- VS mode shall be cleared when the mode annunciations are turned off. 


Modes_Of f_Clears_VS = 

pre VS_Selected and not Modes_On => not VS_Selected; 
check Modes Off Clears VS; 


— FLC MODE 


-- FLC mode shall be selected if and only if FLC mode is active. 


FLC_Selected_If f FLC_Active = 

(FLC_Active = FLC_Selected) ; 

check FLC Selected Iff FLC Active; 


-- FLC mode shall be selected if the FLC switch is pressed while FLC mode is cleared 
-- if VAPPR mode is not active. 


FLC_Switch Pressed_Selects_FLC = 

not pre FLC_Selected and RISING (FLC_Switch) 
and not pre VAPPR_Active 

and No_Higher_Event_Than_FLC_Switch Pressed => FLC_Selected; 
check FLC Switch Pressed Selects FLC; 


-- FLC mode shall be activated if an overspeed condition occurs 
-- while neither ALT or ALTSEL are active. 


Overspeed_Activates_FLC = true -> 
not pre FLC_Active 
and Overspeed 

and not pre ALT^Active and not ALT^Active 

and not pre ALTSEL^Active and not ALTSEL^Active => FLC_Selected; 
check Overspeed_Activates_FLC; 


-- FLC mode shall be cleared if the FLC switch is pressed while FLC mode is selected 
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-- and an overspeed condition does not exist. 


FLC_Switch_Pressed_Clears_FLC = 

pre FLC_Selected and RISING (FLC_Switch) 
and not Overspeed 

and No_Higher_Event_Than_FLC_Switch Pressed => not FLC_Selected; 
check FLC Switch Pressed Clears FLC; 


-- FLC mode shall be cleared if the VS Pitch Wheel is rotated while 
-- an overspeed condition does not exist. 


VS_Pitch_Wheel_Rotated_Clears_FLC = 
pre FLC_Selected 

and RISING (VS_Pitch_Wheel_Rotated) 
and not Overspeed 

and No_Higher_Event Than_VS_Pitch_Wheel_Rotated => not FLC_Selected; 
check VS Pitch Wheel Rotated Clears FLC; 


-- FLC mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_FLC = 

pre FLC_Selected and CHANGED ( Pilot Flying_Side) => not FLC_Selected; 

check Pilot Flying_Transfer_Clears_FLC; 

-- FLC mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears FLC = 

pre FLC_Selected and not Modes_On => not FLC_Selected; 
check Modes Off Clears FLC; 


— ALT MODE 


-- ALT mode shall be selected if and only if ALT mode is active. 

ALT_Selected If f_ALT_Active = 

(ALT_Active = ALT_Selected) ; 

check ALT Selected Iff ALT Active; 


-- ALT mode shall be selected if the ALT switch is pressed while ALT mode is cleared 
-- while VAPPR mode is not active. 


ALT Switch Pressed_Selects_ALT = 

not pre ALT_Selected and RISING (ALT_Switch) and not pre VAPPR_Active 
and No_Higher_Event Than_ALT Switch Pressed => ALT_Selected; 

check ALT Switch Pressed Selects ALT; 


-- ALT mode shall be selected if the ALTSEL target is changed 
-- while in ALTSEL Track mode. 
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ALTSEL^Target Changed_Selects_ALT = 

pre ALTSEL_Track and RISING (ALTSEL_Target_Changed) 

and No_Higher_Event Than_ALTSEL_Target Changed => ALT_Selected; 

check ALTSEL_Target_Changed_Selects_ALT ; 


-- ALT mode shall be cleared if the ALT switch is pressed while ALT mode is selected. 


ALT_Switch Pressed_Clears_ALT = 

pre ALT_Selected and RISING (ALT^Switch) 

and No_Higher_Event Than_ALT Switch Pressed => not ALT^Selected; 
check ALT Switch Pressed Clears ALT; 


-- ALT mode shall be cleared if the VS Pitch Wheel is rotated 
-- while ALT mode is selected. 


VS_Pitch_Wheel_Rotated_Clears_ALT = 

pre ALT_Selected and RISING (VS_Pitch_Wheel_Rotated) 

and No_Higher_Event Than_VS_Pitch_Wheel_Rotated => not ALT^Selected; 
check VS Pitch Wheel Rotated Clears ALT; 


-- ALT mode shall be cleared when there is a pilot flying transfer. 
Pilot_Flying_Transfer_Clears_ALT = 

pre ALT_Selected and CHANGED ( Pilot Flying_Side) => not ALT_Selected; 
check Pilot Flying_Transfer_Clears_ALT; 

-- ALT mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears_ALT = 

pre ALT_Selected and not Modes_On => not ALT_Selected; 
check Modes Off Clears ALT; 


— ALTSEL MODE 


-- ALTSEL mode shall be selected if ALTSEL mode is active. 

ALTSEL_Selected_If_ALTSEL_Active = 

(ALTSEL_Active => ALTSEL_Selected) ; 

check ALTSEL_Selected_If_ALTSEL_Active; 

-- ALTSEL mode shall be active if ALTSEL is tracking the target altitude. 

ALTSEL_Active_If_ALTSEL_Track = 

( ALTS EL_T rack => ALTSEL_Active) ; 

check ALTSEL Active If ALTSEL Track; 

-- If the mode annunciations are on, ALTSEL mode shall be selected if 
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-- none of ALT, VAPPR, or VGA mode are active. 

ALTSEL_Selected_If_Not_ALT_VAPPR_VGA_Active = true -> 

Modes_On and not (ALT_Active or VAPPR_Active or VGA_Active) => ALTSEL_Selected; 

check ALTSEL Selected If Not ALT VAPPR VGA Active; 


-- ALTSEL mode shall become active if the ALTSEL capture condition is met 
-- while ALTSEL mode is armed 


ALTSEL__Active_When_Capture_Cond_Met = true -> 
pre ALTSEL_Selected and not pre ALTSEL_Active 
and ALTSEL_Capture_Cond_Met 

and not (ALT^Active or VAPPR_Active or VGA__Active) 
and Modes_On 

and No_Higher_Event Than_ALTSEL_Capture_Cond_Met => ALTSEL_Active ; 
check ALTSEL_Active_When_Capture_Cond_Met ; 


-- ALTSEL mode shall start tracking if the ALTSEL track condition is met 
-- while ALTSEL 

-- capturing the target altitude 


ALTSEL_Track_When_Track_Cond_Met = true -> 
pre ALTSEL_Active and not pre ALTSEL Track 
and ALTSEL Track Cond_Met 
and not ALTSEL_Target_Changed 
and not VS_Pitch_Wheel_Rotated 
and not CHANGED ( Pilot_Fly ing_Side ) 
and ALTSEL_Active 

and not (ALT^Active or VAPPR_Active or VGA_Active) 
and Modes_On 

and No_Higher_Event Than_ALTSEL_Track_Cond_Met => ALTSEL^Track; 
check ALTSEL Track When Track Cond Met; 


-- ALTSEL mode shall revert to armed mode if the ALTSEL target is changed 
-- while in capture mode. 


ALTSEL_Deactivated_When_Target Changed = 

pre ALTSEL^Active and not pre ALTSEL_Track 
and RISING (ALTSEL_Target ^Changed) 

and not (ALT_Active or VAPPR_Active or VGA_Active) 
and Modes_On 

and No_Higher_Event Than_ALTSEL_Target Changed 
=> (ALTSEL^Selected and not ALTSEL Active); 

check ALTSEL Deactivated_When_Target_Changed; 


-- ALTSEL mode shall revert to armed mode if the VS Pitch Wheel is rotated 
-- while in capture mode. 


ALTSEL_Deactivated_When_VS_Pitch_Wheel_Rotated = 
pre ALTSEL^Active and not pre ALTSEL^Track 
and RISING (VS_Pitch_Wheel_Rotated) 

and not (ALT_Active or VAPPR_Active or VGA_Active) 
and Modes_On 

and No_Higher_Event Than_VS_Pitch_Wheel_Rotated 
=> (ALTSEL^Selected and not ALTSEL Active); 
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check ALTSEL Deactivated When VS Pitch Wheel Rotated; 


-- ALTSEL mode shall revert to armed mode if there is a pilot flying transfer 
-- while in capture mode. 


ALTSEL_Deactivated_When_Pilot_Flying_Transf er = 
pre ALTSEL^Active and not pre ALTSEL^Track 
and CHANGED ( Pilot_Fly ing^Side ) 

and not (ALT_Active or VAPPR_Active or VGA__Active) 

and Modes_On => (ALTSEL_Selected and not ALTSEL^Active) ; 

check ALTSEL_Deactivated_When_Pilot_Flying Transfer; 


-- ALTSEL mode shall revert to armed mode if a new vertical mode becomes active 
-- while in capture mode. 


ALTSEL_Deactivated_When_New_Active_Vert ical_Mode = 
pre ALTSEL^Active and not pre ALTSEL^Track 
and not ALTSEL^Active 

and not (ALT^Active or VAPPR_Active or VGA^Active) 

and Modes_On => (ALTSEL_Selected and not ALTSEL^Active) ; 

check ALTSEL Deactivated When New Active Vertical Mode; 


-- If the mode annunciations are on, ALTSEL mode shall be cleared if 
-- any of ALT, VAPPR, or VGA mode become active. 


ALTSEL_Cleared_If_ALT_VAPPR_VGA_Active = 

Modes_On and (ALT^Active or VAPPR_Active or VGA_Active) => not ALTSEL^Selected; 

check ALTSEL Cleared If ALT VAPPR VGA Active; 


— VAPPR MODE 


-- VAPPR mode shall be selected if VAPPR mode is active. 

VAPPR_Selected_If_VAPPR_Active = 

(VAPPR_Active => VAPPR_Selected) ; 

check VAPPR Selected If VAPPR Active; 


-- VAPPR mode shall be selected if the APPR switch is pressed 
-- while VAPPR mode is cleared. 


APPR_Switch_Pressed_Selects_VAPPR = 

not pre VAPPR_Selected and RISING (APPR_Switch) 

and No_Higher_Event Than_APPR_Switch_Pressed => VAPPR_Selected; 
check APPR Switch Pressed Selects VAPPR; 


-- VAPPR mode shall become active if the VAPPR capture condition is met 
-- while VAPPR mode is armed and LAPPR mode is active and 
-- an overspeed condition does not exist. 
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VAPPR_Active_When_Capture_Cond_Met = true -> 
pre VAPPR_Selected and not pre VAPPR_Active 
and VAPPR_Capture_Cond_Met 
and LAPPR_Active and 
and not Overspeed 

and not Selected_NAV_Source_Changed 
and not Selected_NAV__Frequency_Changed 
and not CHANGED ( Pilot__Fly ing_Side ) 
and Modes_On 

and No_Higher_Event Than_VAPPR_Capture_Cond_Met => VAPPR_Active ; 
check VAPPR_Active_When_Capture_Cond_Met ; 


-- VAPPR mode shall be cleared if the APPR switch is pressed 
-- while VAPPR mode is selected. 


APPR_Switch_Pressed_Clears_VAPPR = 

pre VAPPR_Selected and RISING (APPR_Switch) 

and No_Higher_Event Than_APPR_Switch_Pressed => not VAPPR_Selected; 
check APPR Switch Pressed Clears VAPPR; 


-- VAPPR mode shall be cleared if LAPPR mode is cleared. 


LAPPR_Cleared_Clears_VAPPR = 

pre VAPPR_Selected and not pre LAPPR_Selected => not VAPPR_Selected; 
check LAPPR Cleared Clears VAPPR; 


-- VAPPR mode shall be cleared if the selected NAV source is changed. 

Selected_NAV_Source_Changed_Clears_VAPPR = 

pre VAPPR_Selected and Selected NAV_Source_Changed => not VAPPR_Selected; 

check Selected_NAV_Source_Changed_Clears_VAPPR; 

-- VAPPR mode shall be cleared if the selected NAV frequency is changed. 

Selected_NAV_Frequency_Changed_Clears_VAPPR = 

pre VAPPR_Selected and Selected NAV_Frequency_Changed => not VAPPR_Selected; 

check Selected__NAV_Frequency_Changed_Clears_VAPPR; 

-- VAPPR mode shall be cleared when there is a pilot flying transfer. 

Pilot Flying Transf er_Clears_VAPPR = 

pre VAPPR_Selected and CHANGED (Pilot Flying^Side) => not VAPPR_Selected; 
check Pilot_Flying_Transf er_Clears_VAPPR; 

-- VAPPR mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears_VAPPR = 

pre VAPPR_Selected and not Modes_On => not VAPPR_Selected; 
check Modes Off Clears VAPPR; 
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— VGA MODE 


-- VGA mode shall be selected if and only if VGA mode is active. 

VGA_Selected_If f_VGA_Active = 

(VGA_Active = VGA_Selected) ; 

check VGA Selected Iff VGA Active; 


-- VGA mode shall be selected if the GA switch is pressed 

-- while VGA mode is cleared and an overspeed condition does not exist. 


GA_Switch_Pressed_Selects_VGA = 

not pre VGA_Selected and RISING (GA_Switch) and not Overspeed 
and No_Higher_Event_Than_GA_Switch_Pressed => VGA_Selected; 

check GA Switch Pressed Selects VGA; 


-- VGA mode shall be cleared when the AP is engaged. 


AP_Engaged_Clears_VGA = 

pre VGA_Selected and RISING (Is_AP_Engaged) => not VGA_Selected; 
check AP_Engaged_Clears_VGA; 


-- VGA mode shall be cleared when LGA mode is cleared. 


LGA_Cleared_Clears_VGA = 

pre VGA_Selected and not pre LGA_Selected => not VGA_Selected; 
check LGA Cleared Clears VGA; 


-- VGA mode shall be cleared when the SYNC switch is pressed 
-- while VGA mode is selected. 


SYNC_Switch_Pressed_Clears_VGA = 

pre VGA_Selected and RISING (SYNC_Switch) => not VGA_Selected; 

check SYNC Switch Pressed Clears VGA; 


-- VGA mode shall be cleared when the VS Pitch Wheel is rotated VGA mode is selected. 


VS_Pitch_Wheel_Rotated_Clears_VGA = 

pre VGA_Selected and RISING (VS_Pitch_Wheel__Rotated) 

and No_Higher_Event Than_VS_Pitch_Wheel_Rotated => not VGA_Selected; 
check VS Pitch Wheel Rotated Clears VGA; 


-- VGA mode shall be cleared when there is a pilot flying transfer. 


Pilot_Flying_Transf er_Clears_VGA = 

pre VGA_Selected and CHANGED (Pilot Flying_Side) => not VGA_Selected; 
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check Pilot Flying^Transf er_Clears_VGA; 

-- VGA mode shall be cleared when the mode annunciations are turned off. 
Modes_Of f_Clears_VGA = 

pre VGA_Selected and not Modes_On => not VGA_Selected; 
check Modes Off Clears VGA; 


-- Auxilliary signals used to simplify statement of properties. 


No_Higher_Event Than_SYNC_Switch_Pressed = true; 

No_Higher_Event_Than_GA_Switch Pressed = 

(not RISING (SYNC_Switch) and No_Higher_Event_Than_SYNC_Switch_Pressed); 

No_Higher_Event_Than_APPR_Switch_Pressed = 

(not RISING (GA_Switch) and No_Higher_Event Than_GA_Switch__Pressed) ; 

No_Higher_Event_Than_HDG_Switch_Pressed = 

(not RISING (APPR_Switch) and No_Higher_Event_Than_APPR_Switch_Pressed) ; 

No_Higher_Event_Than_NAV_Switch_Pressed = 

(not RISING (HDG_Switch) and No_Higher_Event Than_HDG_Switch_Pressed) ; 

No_Higher_Event Than_AP_Engaged = true; 

No_Higher_Event_Than_ALTSEL_Target_Changed = 

(not RISING (APPR_Switch) and No_Higher_Event_Than_APPR_Switch_Pressed) ; 

No_Higher_Event Than_ALT_Switch_Pressed = 

(not RISING (ALTSEL_Target_Changed) and No_Higher_Event Than_ALTSEL_Target_Changed) ; 

No_Higher_Event Than_FLC_Switch_Pressed = 

(not RISING (ALT^Switch) and No_Higher_Event_Than_ALT_Switch_Pressed) ; 

No_Higher_Event_Than_VS_Switch Pressed = 

(not RISING (FLC_Switch) and No_Higher_Event_Than_FLC_Switch_Pressed); 

No_Higher_Event_Than_VS_Pitch_Wheel_Rotated = 

(not RISING (VS_Switch) and No_Higher_Event Than_VS_Switch_Pressed) ; 

No_Higher_Event_Than_FD_Switch Pressed = 

( (not RISING (NAV_Switch) and No_Higher_Event Than_NAV_Switch_Pressed) 
and (not RISING (Is_AP_Engaged) and No_Higher_Event_Than_AP_Engaged) 
and (not RISING (VS_Pitch_Wheel_Rotated) and 

No_Higher_Event_Than_VS_Pitch_Wheel_Rotated) ) ; 

No_Higher_Event_Than_LAPPR_Capture_Cond_Met = 

(not RISING (FD_Switch) and No_Higher_Event Than_FD_Switch__Pressed) ; 

No_Higher_Event Than_NAV_Capture_Cond_Met = 

(not LAPPR_Capture_Cond_Met and No_Higher_Event_Than_LAPPR_Capture_Cond_Met) ; 

No_Higher_Event Than_VAPPR_Capture_Cond_Met = 

(not RISING (FD_Switch) and No_Higher_Event Than_FD_Switch_Pressed) ; 

No_Higher_Event Than_ALTSEL Track_Cond_Met = 

(not VAPPR_Capture_Cond_Met and No_Higher_Event_Than_VAPPR_Capture_Cond_Met) ; 

No_Higher_Event Than_ALTSEL_Capture_Cond_Met = 
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(not ALTSEL Track_Cond_Met and No_Higher_Event_Than_ALTSEL Track_Cond_Met) ; 
tel; 


-- RISING - returns true when signal s changes from false to true 


node RISING (s : bool) returns (p : bool) ; 
let 

p = false -> (not pre s and s) ; 
tel; 


-- FALLING - returns true when signal s changes from true to false 


node FALLING (s : bool) returns (p : bool) ; 
let 

p = false -> (pre s and not s) ; 
tel; 


-- CHANGED - returns true when signal s changes value 


node CHANGED (s 

: bool) returns (p : 

: bool) 

let 



p = false -> 

(not (s = pre s) ) ; 


tel ; 
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Appendix C Mode Logic Error Log 


Date 

Location 

Dlassificatior 

Description 

How Resolved 

Notes 

10/4/2012 

Event 

Processing 

Minor 

Incorrect inhibiting of input events. The inhibit In of the 

When_Switch_Pressed_Seen block was wired to the 
output of the next higher priority block. 

Modified the 

When_Switch_Pressed_Seen block to 
output an lnhbit_Out that was the OR of 
the Inhibitjn and the output indicating if 
the event was seen. 

Checking that at least one lateral 
mode is active. 

10/4/2012 

Event 

Processing 

Minor 

LGA_Active being set to false when VGA exits the acti\e 
state. 

Corrected copy and paste error. 

Checking that at least one lateral 
mode is active. 

10/16/2012 

Flight 

Modes 

Moderate 

Incorrectly predicting if a lateral or vertical mode would be 
activated on a step. Failed to account for the case where 
LNAV, LAPPR, ALTSEL, or VAPPR could be cleared at 
the same time the capture condition is met. 

Updated Will_MODEX_Be_Acti\^ted to 
take into account the simultaneous 
occurrence of being cleared at the same 
time as the capture condition is met. 

Checking that at least one lateral 
mode is active and that at least one 
vertical mode is active. 

10/16/2012 

Event 

Processing 

Minor 

Incorrect inhibiting of input conditions. The inhibitjn of 
the lf_Condition_Seen block was wired to the output of 
the next higher priority block. 

Modified the lf_Condition_Seen block to 
output an lnhbit_Out that was the OR of 
the Inhibitjn and the output indicating if 
the condition was seen. 

Checking that at most one vertical 
mode is active. 

10/16/2012 

Flight 

Modes 

Major 

Two vertical modes active at the same time caused by 
an Overspeed condition selecting FLC mode at the same 
time the ALT switch is pressed. 

Modified the condition for selecting FLC 
mode so that FLC mode is not selected 
if ALT or ALTSEL are already active or 
will become active on this step. 

Checking that at most one vertical 
mode is active. 

10/16/2012 

Flight 

Modes 

Moderate 

Two vertical modes active at the same time caused by 
pressing the FLC swtich while ALTSEL Capture is active. 

Fixed the definition of 
Will_FLC_Be_Active by removing the 
condition that Clear FLC be false. 

Checking that at most one vertical 
mode is active. 

11/20/2012 

Mode Logic 

Minor 

NAV_Switch input incorrectly named NAV_Swiitch. 

Changed the name of input to 
NAV_Switch. 

Checking definition of 

No_Higher_Event_Than_FD_Switch_ 

Pressed. 

11/28/2012 

Flight 

Modes 

Moderate 

Execution sequence of Independent and Active mode 
machines was incorrect - Independent was assigned an 
execution order of 5 and Active was assigned an 
exectuion order of 6. This placed their execution after 
Lateral and Vertical had executed. 

Changed the execution order of 
Independent to 3 and the execution order 
of Active to 4. 

Checking that onside and offside 
VAPPR active implies the FGS is in 
Independent mode. 

11/29/2012 

Flight 

Modes 

Moderate 

A pilot flying transfer did not make PITCH mode active 
while ALTSEL was active. 

Added a deactivate transition from 
ALTSEL.Active to ALTSEL.Armed mode. 

Checking that a Pilot Flying Transfer 
should make PITCH mode active. 

11/29/2012 

Flight 

Modes 

Major 

ROLL mode was not active while the mode annunciations 
were off. 

Simplified definition of 
Lateral_Mode_Manually_Selected and 
Veritical_Mode_Manually_Selected to 
not test if mode annunciations were off in 
the previous step or if this side is active. 

Checking that ROLL mode is active 
while the mode annunications are 
off. 

11/29/2012 

Flight 

Modes 

Major 

PITCH mode was not active while the mode 
annunciations were off. 

Changed definition of 
Vertical_Mode_Manually_Selected to not 
if this side is active when the ALTSEL 
target altitude is changed while ALTSEL 
mode is tracking. 

Checking that PITCH mode is active 
while the mode annunciations are 
off. 

12/7/2012 

Mode Logic 

Minor 

Selected_NAV_Source_Changed and 
Selected_NAV_Frequency_Changed incorrectly named 
Selected_Nav_Source_Changed and 
Selected Nav Frequency Changed. 

Changed spelling to 
Selected_NAV_Source_Changed and 
Selected J'JAV_Frequency_Changed. 

Checking that NAV mode becomes 
active when the NAV capture 
condition is met. 

12/13/2012 

Flight 

Modes 

Moderate 

Truth table for ALT Select was overspecified. Stated that 
ALT mode should be selected if the ALTSEL target was 
changed while in ALTSEL Track mode and not in VAPPR 
Active mode. The dependence on VAPPR Active mode 
was not needed since ALTSEL Track is an active mode 
and only one vertical mode can be active at a time. 

Changed the dependence on VAPPR 
Active to a don't care in ALT Select truth 
table. 

Checking that ALT mode is selected 
when the ALTSEL target is changed 
while in ALTSEL Track mode. 

12/17/2012 

Flight 

Modes 

Major 

Transitions between ALTSEL Clear and ALTSEL 
Selected would occur on the current step if ALT mode 
became active/inactive and on the next step if VAPPR or 
VGA became active/inactive. This occurred since the 
order of executing these state machines was ALT, 
ATLSEL, VAPRR, followed by VGA. 

Changed the order of execution of 
ALTSEL to follow execution of ALT, 
VAPPR, and VGA modes. 

Found checking that ALTSEL mode 
is selected iff none of ALT, VAPPR, 
or VGA modes are active. While the 
error was not serious (the necessary 
transition would occur in the current 
or next step), it would be difficult to 
detect through testing. 

12/17/2012 

Flight 

Modes 

Moderate 

Turning the mode annunciations off only deactivated 
ALTSEL mode (i.e. took it from ACTIVE to ARMED 
mode). Turning the mode annunciation off should clear 
ALTSEL mode (i.e. take it from SELECTED to 
CLEARED mode). 

Moved column enabling a transition when 
the modes are turned off from the 
ALTSEL Deactivate truth table to the 
ATLSEL Clear truth table. 

Found checking that ALTSEL mode 
is selected iff none of ALT, VAPPR, 
or VGA modes are active. 

12/18/2012 

Flight 

Modes 

Major 

Possible to have two modes active at the same time if an 
overspeed condition occurs (activating FLC) at the same 
time as the ALTSEL capture condition is met (activating 
ALTSEL Capture). 

Strengthened the ALTSEL Capture() truth 
table to not capture ALTSEL mode while 
an overspeed condition exists. 

Checking at most one vertical mode 
active while adding Active Side 
logic. 



Classification 



Trivial 

0 Spelling or Punctuation 



Minor 

5 Likely to be detected by traditional verification. 



Moderate 

6 Potential to not be detected by traditional verification. 



Major 

5 Unlikely to be detected by traditional verification. 
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